At 10:09 AM 7/07/2006, you wrote:

>Thanks you Helen, this is the information I needed. We can now state
>to our customer that they need to setup two port forwarding rules for
>NAT or allow incoming connections on two ports if they have a
>firewall. Luckily we have deployed SuperServer currently because
>according to Milan's PDF it will not work for classic server.
>
>What I am suggesting I hope is a generic answers though my previous
>post was very long winded as I was not sure how events were currently
>implemented. However my answers may not be correct/work but you never
>know if you never ask.

Well, I'm in the same state - looking for things to try.

>1. Can't Firebird use known NAT traversal techniques to yield a new
>connection?

In short, no. The Firebird client doesn't control the network: it's
a layer above the network transport. NATs are also layers above the
network transport. Firebird asks for sockets and responds when it
can't get them. The resolution underneath has to do with the
operating systems of the client and server and the network transport
that it is responding to but it doesn't know anything about the
sequence of events that occurred in other layers, that led to refusal
or breakage of a socket.

>Is classic server not already doing this as according to
>Milan's PDF when someone connects on 3050 to the database a new server
>process is spawned(without using events) for the user connecting does
>this not encounter the same problem and if not why(I have not tried
>this)?

I was unable to download the paper, so I can't comment. But the
process per se doesn't "use events". Client programs and
user-written PSQL modules use them. Events don't "kick in" until
they are used. To use events, the application has to create a
callback routine on the server and then make calls to this
routine. For the server's part, when it needs to pass an event to
the events table, it asks the NOS for a port to use as a channel. If
it can establish a socket to this port, events will work. If it's
refused, Stuff Doesn't Happen.

The default behaviour is for the server not to care which port it's
going to use. AFAICT, it also doesn't have any way to know that it
didn't get the port - it just assumes that a port is
available. RemoteAuxPort was introduced in 1.5 to enable you to
configure an explict port for event traffic, to get past this
problem. But the engine *still* doesn't have any way to know whether
it succeeded or failed in getting the port it asked for. So, if the
firewall and/or the NAT haven't been configured for the port and the
redirection respectively, then the job is not done.

Firebird supports (i.e. should support) server redirection, e.g.
router.address:internal.address/9999:path/to/databasefile so,
according to my current (deficient) understanding, as long as things
are properly configured in the firewall and the router's NAT, the
external connection through port 9999 on the internal server's node
should work. However, this mechanism has been broken all of
Firebird's life and has been fixed in Fb 2.0.

As you can tell, I only understand part of the picture. I want to
understand the whole picture and write a configuration guide for
it. I'll continue to try to get someone to give me a definitive
description (so far elusive). Or, maybe, between us, we can figure
it out by trial and error.

>Why can it be done for the initial connection and not for events?

Events are client-initiated, i.e. if the client doesn't "plant" a
callback routine on the server, there are no events. (Most API
interpretation layers DO provide such a routine that the application
can call transparently...)

>2. Even if Firebird can not yield a connection should it be
>locking/stalling/crashing the server forcing me to kill the Firebird
>process and restart it?

I guess it boils down to whether a programmer/deployer has all the
ducks lined up in the network layer and has verified that his
callback routine actually works. The server can detect the presence
of the callback routine but it's external to the engine so it doesn't
have any way to know whether a callback call worked properly or
crashed or corrupted memory or whatever. On the client side, if the
client is registering events that are going nowhere, I suppose it
won't be long before memory violations occur...

It's precisely because this whole area is grossly under-documented
that I want to pool all the available knowledge and write something
that actually gives a blow-by-blow description of which things to
configure, and how, for the various environments.

./heLen