Bugs fixed Firebird 2.0: Remote interface bugs

<< Crash conditions | Firebird 2.0.7 Release Notes | Indexing and optimization >>

Bugs fixed

Firebird 2.0: Remote interface bugs

Not registered A TCP/IP buffer size larger than 32 Kb was not being processed correctly.

fixed by A. Peshkov

~ ~ ~

Not registered The NO_NAGLE option was working improperly.

fixed by F. Polizo, A. Peshkov

~ ~ ~

Not registered NO_NAGLE and KEEPALIVE socket options were not enabled for CS builds.

fixed by D. Yemanov

~ ~ ~

SF #1385092 A TCP/IP connection would appear to freeze the Superserver if it was disconnected abnormally while a large packet, e.g. a BLOB or a large SQL request, was being passed across the interface. This was a long-standing InterBase/Firebird bug in the implementation of the protocol layer for Superserver on Windows. Borland invented two different thread management strategies: one for TCP/IP and one for the other protocols that only Windows supports, i.e. Named Pipes (sometimes referred to as “NetBEUI”) and the IPServer local connection. This bug occurred only with TCP/IP connections.

For TCP/IP, a multiplexing loop (main server loop), which is common for all ports, receives API packets from clients, creates requests and sends them to threads for processing. When it detects an incoming packet, it starts to receive it from the port.

Before this fix, it needed the entire API packet to come at once. However, in the course of converting a packet to a request (done by the XDR protocol), in cases where the size of the API packet happened to be greater than that of the network packet, the server had to wait for the next network packet from the port. At this point, ports were being scanned for incoming packets only by calculating (timeout - interval since last packet received) for each port in the loop. If the next packet from a particular port did not come, for example because of an unplugged jack, the only way to interrupt this receive and allow the main server loop to carry on processing the other ports was to wait for the keepalive TCP timeout to elapse on the abandoned connection.

Given that the default keepalive value is two hours, it would appear that the Superserver was "hung".

fixed by A. Peshkov

~ ~ ~

SF #1260310 Nessus vulnerability scanning could cause the server to drop connections.

fixed by A. Peshkov

~ ~ ~

SF #1065511 Clients on Windows XP SP2 were slow connecting to a Linux server.

fixed by N. Samofatov

~ ~ ~

SF #1065511 Clients on Windows XP SP2 were slow connecting to a Linux server.

fixed by N. Samofatov

~ ~ ~