Darryl Miles wrote: >David Schwartz wrote: >> Joakim Tjernlund wrote: >> A "hung connection" *should* remain locked if the client stops reading from >> its socket. The client might continue reading from its connection in a day, >> a week, or a year. If the server wants to timeout the connection, it can and >> should do so. > >I agree with David's comments. Maybe Joakim should try to remember the >details, as the devil is in the details. In particular EAGAIN should >only be observed from the operating system when the socket is put into >non-blocking mode. > >Observing an EAGAIN from a write() or send() system call is an >indication that the sending side is able to queue data faster than the >receiving side is able to dequeue it. This is a normal, anticipated and >expected condition, not an error. This is usually the case with most >applications, since the receiving side has to also account for: > * Network congestion, temporary network blockage/failure > * Network propagation delay (round trip time) > * TCP Protocol congestion window (it takes an amount of time for the >TCP window to open up, in the order of 6xRTT) > * The time it takes the program at the remote end to call >read()/recv() on the network socket. > * Often also the processing time for the data (often the >biggest/slowest factor) > >The sending side only has to account for: > * Ability to generate the data and hand it to the kernel. Modern >disks subsystems can be doing over 100Mb/sec, this is faster then even >gigabit ethernet. > >Is it normal to deal with this issue by using select() or poll() (or >similar) to perform a limited wait, the kernel will then return control >back the to application once either the socket becomes writable (the >EAGAIN condition has gone, in which case you retry your write()/send()) >or a timeout has expired (in which case you can then decide to take >action and turn the EAGAIN condition yourself into a close of socket >making it fatal). The select() and poll() kernel system calls provide a >way for the application to give up its CPU timeslice and get it back >again when the temporary I/O wait condition has cleared. Win32 API has >WaitForSingleObject() which does a similar thing.
Sure, but this is the BIO interface and I am at loss on how to do this with BIO. It seems like I am stuck somewhere inside BIO and it keeps retrying. Jocke PS. Please keep me on CC: ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
