> Hi
>
> A number of our sites are getting intermittent disconnections from FB
> SS. One or more machines comes up with a message, that I currently
> don't know as the client can't remember !
>
> Looking in the Firebird log file I see errors like below...
>
> COUNTERMAIN (Client) Wed Sep 20 06:55:40 2006
> INET/inet_error: send errno = 10054
>
> and
>
> COUNTERMAIN (Client) Sat Sep 30 07:48:08 2006
> INET/inet_error: connect errno = 10061
>
> These look like they could be the culprit. The Client has recently
> moved their shops to be connected in a WAN via a VPN (over XDSL). The
> hardware guy says there is nothing obviously wrong with the system. The
> branch as a fixed IP for the machine running FB server. Each branch and
> HO have a static IP.
>
> FB is being used at each branch locally (each branch has a copy of our
> software that they previously used before the VPN). However every hour
> or so a small other app runs that connects to FB over the VPN and sucks
> out some data. The crashes do not seem to time in with when this
> app runs.
>
> I am sorry I cant give the exact error message but I suspect is
> something like 'Connection forcably closed by host', I have asked them
> to note it down for next time. The error seems to occur about once a day.
>
> Any help would be appreciated :)
> --
> Rob Martin

from my experience some years ago:
I have had 4 x IB5.6 servers replicating to each other (i.e. 4 x 2-way
replications or 4 x 3 vectors) since early 1998 with out error.

The network is a mix of LAN/Frame Relay/ISDN over both internal lines and
via a TELSTRA provided VPN setup.

Without my knowledge, at around Christmas 2002, my client was encouraged to
switch (perhaps forced) to a TPIPS network link for the most disparate link.
When this happened (I have since learned of the timing), the replication
stopped in one vector only between only 2 of the servers (i.e. 1 vector of
the possible 12 vectors)

After doing many things including reinstalling the TCP/IP transport layer on
both ends of this direction, there appeared no solution. I was finally down
to forcing TELSTRA to listen to my problem. They did. They sniffed my
attempts to maintain a connection. I could authenticate in the questionable
direction but I could not sustain the socket connection for even a small
amount of schema (meta) data transport.

On analysing the packet traffic they realised that, in this one vector, the
TPIPS network is forcing packets to be separated, even though the IB socket
connection request (or whatever the terminology for it is) has the "don't
separate" bit set to true. The TPIPS network is also set for "diversity"
which I think means, the route in one direction may not be the same as the
reverse direction and possibly, that the packets may not follow the same
route for a single line of communication. Sounds great doesn' it.
------
This was resolved finally by a setting on the network connection to stop
separating the packets.
Alan