At 03:53 AM 15/02/2008, you wrote:

>This is very difficult to describe. It's like the connection to the
>server pauses. The connection to the database is done via a VPN
>tunnel. At some customer sites this works wonderfully and at some I
>experience this problem.
>
>If I'm connecting and downloading metadata (a query with a somewhat
>big resultset to bring down to the client) or doing table compares in
>IBExpert and I bring up the "Status Dialogue" for the VPN tunnel and
>look at the activity counters - I can see that I am (the client, that
>is) sending a couple of hundred bytes every say 0.5 seconds. The
>server responds with a couple of hundred bytes with a somewhat longer
>delay between them. This would be the "paused" state. Then suddenly
>the server responds with *much* more data in every update of the
>dialogue (I'm not an expert on packets and such) and that is when the
>application on the client side behaves as it should. That would be my
>problem description (sorry for being so vague).
>
>But this small bursting negotiation-like seems to go on even though
>theres no connection, no FB client software running, so the pauses may
>be really silent on the FB part of the line.
>
>One customer site has very long "pauses" between very short "non
>pauses". Another client has short "pauses" and the "non pauses" are so
>long that one even thinks the problem has gone away.
>
>I'm stumped. These tunnels used to work great both with IBExpert and
>my Client. The worst case is a 1.5.x database hosted on a separate
>linux machine. I can see the behaviour with 2.0.1 databases too. When
>I run the application I always use the 2.0.1 client library
>(fbclient.dll) but when I run IBExpert I target the library to match
>the server version. So that does not seem to be the problem.
>
>Any takes? I really don't know where to start *at all*. I vaguely
>remember something about NONAGLE, can that be it?

I don't know the answer and can't test anything about it myself. Just some clues perhaps, and a request that you keep this thread alive until you do alight on a solution.

1. The default TcpNoNagle setting is different between Fb 1.5 and Fb 2. In Fb 1.5 it is 0 (Nagle's algo enabled) whereas in Fb 2 it is 1 (Nagle's algo is disabled).

2. Reading the lit, it's not obvious which setting is better for SSH. From a brief scanning with Google, it seems there might be problems (delayed acks and lost packets/high levels of retransmits) on some platforms when the setting in the PuTTY client is different to what the SSH server expects. SSH protocol version might play a part as well.

I'm using puTTy v.0.55 and Nagle's algo is disabled by default in all client configs. I've never changed it. I regularly tunnel to the ibphoenix.com, firebirdsq.org and atkin.com servers and, less regularly, to the sourceforge.net servers, from the eastern Pacific to eastern US and eastern Canadian locations, respectively. Qualitatively, response from the ibphoenix and sourceforge servers is instantaneous whereas firebirdsql.org is deadly slow and atkin.com is somewhere between. I've often supposed it might have something to do with Nagle's. I'm not connecting to Firebird databases in any of these cases, though...

So, just some guesswork that might be clues...or not...

./heLen