Re: [firebird-support] Immediate Detection of Disconnected Clients on Classic
On 25.04.2017 o 17:03, hv...@users.sourceforge.net [firebird-support] wrote: > [...] > I don't actually think Firebird can detect client disconnection > "immediately" when there is no data exchange between the server and the > client (it would require some kind of heartbeat increasing traffic and > would be based on timeouts, which are tricky), otherwise byzantine > network partitions wouldn't be so nasty. > > > Firebird can do it even if there is no data exchange because it always > listens all > known client socket. When OS closed socket it is detected by Firebird > listener. > > Regards, > Vlad OK, that would require another rather lengthy (and probably boring for most readers) explanation, but skpping the details: when a TCP connection (a socket) is closed "normally", there's some handshaking performed between the endpoints (FIN and FIN ACK packets being exchanged). And in that case a TCP socket can detect "immediately" that the other party has just closed its socket. Another scenario: the client simply crashes without properly closing its socket and the client OS reclaims the resources. As soon as the server (which doesn't know yet that there is no client app any more) tries to send a packet to a nonexistent client socket, it gets a response from the client OS (not the client app - there is none), that the endpoint is invalid (a RST packet, followed by a SYN-RST sequence, if I remember correctly, but that's irrelevant). That's another case when the server can detect the client failure, but the detection takes place at the moment of the next data transmission to the client (and there might be none for quite a long time - unless the server does some kind of heartbeat with all its clients). However, when you have a client - server connection, and the packets travel via many routers in between, and one of the routers fail, there's just no traffic going either way (no FIN, ACK, RESET packets get through). In this case neither side knows what's going on - is there a network failure, has the other side crashed, or just the network got really slow. The server sends some data and nothing comes back (neither ACK nor RESET), so the TCP protocol retries the transmission after some time (again no response), it tries again etc., and after the final timeout (which is implementation-dependent) it considers the connection to be unusable and closes the socket (and that's the moment the server process gets notified). If you've started to yawn in the middle of my argument, don't worry - I'm used to that ;) Just wanted to point out there's no magic in TCP and if you partition the network and no control packets can be exchanged, there's no way you can detect what really happened. So let's not blame Firebird for keeping open connections to dead clients for some time, that's not its fault. regards Tomasz -- __--==--__ __--== Tomasz Tyrakowski==--__ __--==SOL-SYSTEM==--__ __--== http://www.sol-system.pl ==--__ __--==--__
Re: [firebird-support] Immediate Detection of Disconnected Clients on Classic
---In firebird-support@yahoogroups.com, wrote : On 24.04.2017 o 10:41, atunccekic@... mailto:atunccekic@... [firebird-support] wrote: > We have some desktop applications which are connecting to firebird, started > crashing for a while. > These applications are mostly on our wireless link connected building so I'm > suspicious about the network. > Then I created a new test project. When I run the application, connect to > the database, disconnect the client network just for a second and reconnect > the network again, the database connection is broken and the application > can't continue. > Then I saw a new feature on firebird 2.5 like this: > Immediate Detection of Disconnected Clients on Classic Vladyslav Khorsun > The Classic server now detects immediately when a Classic process has been > broken by a client disconnection. Its response is to terminate any pending > activity, roll back the active transaction and close the network connection. > Tracker reference CORE-818. > Can this be the reason that a short interruption on the network causing the > problems on the application? > Can this feaure be disabled so that I can see if this is the problem or not? Hi, My answer is based more on the way the networs work than the actual knowledge of FB internals. If you work on a wired network and the network interface is set up to auto detect the link availability (in most cases it is), pulling the network plug out and connecting it back causes the network interface to reset (all sockets are closed, the interface is set up from zero). However, if the network is disrupted somewhere in between the end points (your server and client) but both of them have the physical link up, both the server and the client keep the sockets open (eventually re-transmitting TCP packets after some timeouts), because they simply can't know why there's no traffic on the link - failure or just nothing to say ;). When the network gets operatinal again, it's possible that the database connection actually is still valid and the app keeps working like nothing happened. In case of wireless, every disconnection is like pulling the plug - the interface resets and all sockets are closed. That might explain why your crashes occur mostly on clients connected via wifi. Very good and correct explanation I don't actually think Firebird can detect client disconnection "immediately" when there is no data exchange between the server and the client (it would require some kind of heartbeat increasing traffic and would be based on timeouts, which are tricky), otherwise byzantine network partitions wouldn't be so nasty. Firebird can do it even if there is no data exchange because it always listens all known client socket. When OS closed socket it is detected by Firebird listener. Regards, Vlad
Re: [firebird-support] Immediate Detection of Disconnected Clients on Classic
On 24.04.2017 o 10:41, atuncce...@duzen.com.tr [firebird-support] wrote: > We have some desktop applications which are connecting to firebird, started > crashing for a while. > These applications are mostly on our wireless link connected building so > I'm suspicious about the network. > Then I created a new test project. When I run the application, connect to > the database, disconnect the client network just for a second and reconnect > the network again, the database connection is broken and the application > can't continue. > Then I saw a new feature on firebird 2.5 like this: > Immediate Detection of Disconnected Clients on Classic Vladyslav Khorsun > The Classic server now detects immediately when a Classic process has been > broken by a client disconnection. Its response is to terminate any pending > activity, roll back the active transaction and close the network connection. > Tracker reference CORE-818. > Can this be the reason that a short interruption on the network causing the > problems on the application? > Can this feaure be disabled so that I can see if this is the problem or not? Hi, My answer is based more on the way the networs work than the actual knowledge of FB internals. If you work on a wired network and the network interface is set up to auto detect the link availability (in most cases it is), pulling the network plug out and connecting it back causes the network interface to reset (all sockets are closed, the interface is set up from zero). However, if the network is disrupted somewhere in between the end points (your server and client) but both of them have the physical link up, both the server and the client keep the sockets open (eventually re-transmitting TCP packets after some timeouts), because they simply can't know why there's no traffic on the link - failure or just nothing to say ;). When the network gets operatinal again, it's possible that the database connection actually is still valid and the app keeps working like nothing happened. In case of wireless, every disconnection is like pulling the plug - the interface resets and all sockets are closed. That might explain why your crashes occur mostly on clients connected via wifi. I don't actually think Firebird can detect client disconnection "immediately" when there is no data exchange between the server and the client (it would require some kind of heartbeat increasing traffic and would be based on timeouts, which are tricky), otherwise byzantine network partitions wouldn't be so nasty. hope this helps cheers Tomasz -- __--==--__ __--== Tomasz Tyrakowski==--__ __--==SOL-SYSTEM==--__ __--== http://www.sol-system.pl ==--__ __--==--__
[firebird-support] Immediate Detection of Disconnected Clients on Classic
Hi, We have some desktop applications which are connecting to firebird, started crashing for a while. These applications are mostly on our wireless link connected building so I'm suspicious about the network. Then I created a new test project. When I run the application, connect to the database, disconnect the client network just for a second and reconnect the network again, the database connection is broken and the application can't continue. Then I saw a new feature on firebird 2.5 like this: Immediate Detection of Disconnected Clients on Classic Vladyslav Khorsun The Classic server now detects immediately when a Classic process has been broken by a client disconnection. Its response is to terminate any pending activity, roll back the active transaction and close the network connection. Tracker reference CORE-818. Can this be the reason that a short interruption on the network causing the problems on the application? Can this feaure be disabled so that I can see if this is the problem or not? Thank you
