fixed lag bug in client-ssl patch

[Aaron Sethman]

On Wed, 20 Apr 2005, Joshua Kwan wrote:

> Steve:
>
> Stephen Shirley wrote:
>> Hi,
>>     Didn't know if i should file an official bug with debian as
>> client-ssl isn't enabled by default. Anyway, after months of soul
>> crushing lag, i found the problem.
>
> You are a god among men. If I were 21, I'd buy you enough beer to last a
> lifetime...
>
> CC:ing this reply to the Hybrid user/developer list - many people have
> been searching for a solution to this problem.
>
> I'll see how it applies to 7.1-CURRENT, but this is definitely a huge
> step in the right direction. Thank you thank you thank you!
>
> Including the rest of the message for the list's benefit:
>
>>     Basically, tcp is a bitstream, ssl isn't. Ssl sends data over tcp in
>> chunks it calls records. SSL_read() will only return data whenever a
>> full record has been recieved and decrypted. The lag problem occurred
>> when multiple records arrived at once. The sigio comms handler would
>> only get one read signal, read_packet() only call SSL_read() once,
>> returning the first record. The rest would sit in the input buffer until
>> another packet arrived, at which time the oldest record would be read
>> in, with all the others still being left in the buffer.

Just for an FYI, you *always* must call read/recv until you get EAGAIN for 
RT sigio to work correctly, the same goes for send/write.  You'll only
get event notifications when the socket changes state from EAGAIN to being
ready for read/write.  If you don't do this, the rtsigio code will 
eventually stop responding to sockets.  The current hybrid tree doesn't
do the correct thing in this regard.

This is the difference between level-triggered events (poll,select) and 
edge triggered events.

Aaron