> This topic has been covered before on this list. I do not share David's > beliefs on this matter, the select() readability and writability > indicators are indeed sticky. > > That is they never disappear unless the application permits them too.
That is not only not implemented by any known implementation but quite literally impossible. Please tell me what implementation guarantees that a TCP 'write' after a 'select' hit for writability will not block. > What I mean by this is that the application is in 100% control of its > behavior and it has to take one of the following actions to allow a > indicator condition to be re-evaluated and therefore disappear: > > * close the fd > * perform a single read()/write() (or any other similar operation, such > as recv()/send() etc..) > * issue another select() system call that asks to re-evaluate that same fd So all thos implementations that give a 'readability' hit on a listening socket and then block in 'accept' if there's a subsequent error on the connection don't exist? > Although David has theorized on the possibility of an operating system > receiving a UDP packet from another host, then indicating readability > via select() to the application, then the operating system decides to > chuck away that UDP packet (so its no longer there for a block recv() to > find immediately) this just does not happen. Umm, Linux does this. That's what caused the inetd denial-of-service attack. It's precisely people following the bad advice you are giving that created this problem. > Maybe he is confusing tail > queue dropping with head queue dropping, where the head is the front of > the queue which the application sees next and the tail is the end of the > kernel's buffer space. It doesn't matter what you drop. > The challenge here is for someone to point out by way of pointing to > published source of a BSD socket implementation that will remove all > packets from the socket queue after having already advised a readability > indicator to the application. Huh? You can't get a guarantee out of the lack of documentation. > Given that Window's BSD socket implementation clear states it will not > block there is no need to audit this specifically. There are numerous > other implementations freely available on the Internet to audit and > confirm this point. Unfortunately, on Windows, you have to be able to talk to multiple socket implementations. There is no guarantee that a Windows application only has to deal with the Windows native socket service provider. Firewalls, for example, often interpose their own LSP. These LSPs have been known to have slightly different semantics from the Windows native ones. There are known firewalls that decide which UDP packets to drop at receive time, for example. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
