Daniel Walker diwalker@earthlink.net writes:
I noticed that WSAEnumNetworkEvents() was returning all events that had occurred and not just the events that had been selected with WSAEventsSelect(). Win98 will trigger the event object for all events but WSAEnumNetworkEvents() (in win98) would return zero if the event hadn't been selected. I was trying to gain compatibility with win98.
I'd suggest doing the masking in WSAEnumNetworkEvents then.
An FD_READ event with a zero buffer would mean that the other side closed the connection so it would be equivalent to a POLLHUP from poll() .. I didn't find an occasion when poll() actually returned POLLHUP when the socket closed, on Linux anyway. The application that I was testing got confused when recv() returned zero. Even though recv() can legally return zero, I think non-blocking applications are going to be looking for FD_CLOSE events as opposed to recv() returning zero.
But FIONREAD can return 0 bytes even when the socket isn't closed (for instance if another thread got the data first). You can only determine that it was really closed when you do the actual read. So I don't really see how we can avoid having recv() return zero; well maybe we can make it return EWOULDBLOCK and tell the server the connection is closed, but I'm not sure it's any better.