Subject | Re: [firebird-support] Re: Firebird stops working, when using zebedee and register events |
---|---|
Author | Daniel Rail |
Post date | 2003-11-26T18:13:44Z |
Hi,
At November 26, 2003, 12:42, omar l m rosa wrote:
events, it's even supposed to be configurable to use the same port as
the client connections. The default is use a random port that is
available, this is what causes problems with firewalls and maybe
proxies. And, I think there were some modifications(FB 1.5) to prevent
FB to hang in the event that it doesn't get feedback from the client
(don't take my word for it though, I'm just about 25% certain).
Now, that FB 1.5 is close to release, I think that modifying the
behavior should be addressed in FB 2.0. Especially, that the wire
protocol is going to be revised, or possibly a new one created,
although there are at least 2 that exists(symmetric and asymmetric).
The new protocol will give better performance over the existing
protocol over a WAN, that is the goal to be achieved in FB 2.0. So,
while a new protocol is designed, why not review how the events
communicate with the client.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)
At November 26, 2003, 12:42, omar l m rosa wrote:
> When the client register the event in the server, create a listen connectionIn FB 1.5, you can configure on the server which port is used for the
> using the first port number available in client machine. In server side,
> ib/Fb try to connect to this port, to control the events. If this
> connection, from the server to the client canĀ“t be made, server hungs, or
> probably still eternaly waiting for client response. Therefore, if a
> firewall drop the connection, Ib/Fb hung. I think this had corrected in
> Fb 1.5
events, it's even supposed to be configurable to use the same port as
the client connections. The default is use a random port that is
available, this is what causes problems with firewalls and maybe
proxies. And, I think there were some modifications(FB 1.5) to prevent
FB to hang in the event that it doesn't get feedback from the client
(don't take my word for it though, I'm just about 25% certain).
Now, that FB 1.5 is close to release, I think that modifying the
behavior should be addressed in FB 2.0. Especially, that the wire
protocol is going to be revised, or possibly a new one created,
although there are at least 2 that exists(symmetric and asymmetric).
The new protocol will give better performance over the existing
protocol over a WAN, that is the goal to be achieved in FB 2.0. So,
while a new protocol is designed, why not review how the events
communicate with the client.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)