|Subject||RE: [firebird-support] Re: pumping very large records (30 megs!)|
> do you remember the subject of your post, or the approximate date?This is what happened to me.... I'm not betting this is exactly your case
> that would help my research.
> Thanx for you help,
but it may go to show what it might be.
If you have tested server stability locally, then maybe this (some of it may
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
replication software is the Paul Beach et al IBReplicator (of several years
gone by) firing hourly.
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.