--- In firebird-support@yahoogroups.com, "Milan Babuskov" <milanb@...>
wrote:

> No, not currently. Firebird is unaware of the fact it's begin >NAT-ed.

Would it help under the circumstances I have described if it did
though? You seem more qualified than me to answer such things? Also do
you have any thoughts as to why the server is locking up? Is it
something our program is not doing correctly or is this a bug in
Firebird where events that are trying to establish a connection and
can't crash the database server?

> > Is classic server not already doing this as according to
> > your 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
>
> New spawned process takes the connection handle and moves it to
> another port. I see what you're getting at (doing the same thing for
> events), but it isn't that simple. Initial connection is not handled
> by FB CS itself. It's inetd that listens on port 3050.
>
> > Why can it be done for the initial connection and not for events?
>
> Some things would need to be done, that aren't simple. First, we would
> have to have a separate event-spawner program which would be launched
> from inetd. That would give problem that you need to configure inetd
> to use the port. Event-spawner would then have to spawn a special
> version on FB server that only works with events. That program would
> also need to get in sync with it's "main" FB CS process. All of this
> complicates things a lot, and I doubt it can be done at all.

Wouldn't the FB CS process that the client is connected to act as the
inetd(port issuer) does but instead do so for events the client
registers? Just like when a client register for an event in
SuperServer it is the existing connection the client is using that
issues requests for a port from the OS and sends it to the client? In
theory I believe this should be applicable to events if the same thing
is happening for inetd and its spawned CS process. But I do understand
this is complex as there will be a great deal more threads/processes
needing synchronization caused by the events.

> What I would recommend to Firebird developers is to add a config
> setting for ClassicServer, called EventPortRange or something like
> that. You could then specify that FB should use ports in range (for
> example) 10000-11000 and Classic would take one of those when it
> selects a random port. At your firewall, you can easily forward all
> the traffic in that range, and everything would be fine.

That sounds like a fair solution as well. I could then just put a
count in the database that the clients check before raising an event
to ensure their is a port available/ready. But I must be miss
understanding something. If this is all Classic needs for this to
work, that must mean that the complex thread/process synchronization I
talked about above has already been done? Hence why not change it to
use a system like inetd to spawn event connections?

> Perhaps it could be added to "Whitepaper" section at Firebird >website?

I believe thats a good idea as events in the database are an
attractive feature. Making people aware of how they work is important.

Anyway I think I may have stumbled a bit beyond my depth with this
discussion. I might leave it to other or the devs to work out this one.

My apologies to everyone for the multiple posts. Yahoo can sometimes
publish my posts instantly and other times it takes a while so I need
to be more patient.

Regards Jarrod