Amos, thanks for the ideas. I thought about poll and will look into this. I'm cecking read also for errors (valies < 0) but in this case there ven can not be errors. Since the socket is disconnected, select does not detect any event on this socket and so does not give me any opportunity to read from it and even get an error. But thanks anyway. Rafi.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Amos Shapira Sent: Monday, May 14, 2007 1:16 PM To: Linux-IL Subject: Re: need some help with tcp/ip programming On 14/05/07, guy keren <[EMAIL PROTECTED]> wrote: Rafi Cohen wrote: > Reading some documentation on tcp/ip programming, I had the impression > that the select mechanism should detect such remote disconnect event, > thus enabling me to make a further "read" from this socket which should > end in reading 0 bytes. Reading 0 bytes should indicate disconnection > and let me disconnect propperly from my side and try to reconnect. > However, it seems that select does not detect all those disconnect > events and even worse, I can not see any rule behind when it does detect > this and when it does not. select does not notice "disconnections". it only notices if the socket was closed by the remote side. that's a completely different issue, and that's also the only time when you get a 0 return value from the read() system call. I think you are tinkering with semantics and so miss the real issue (do you work as a consultant? :). Basically - Rafi expects (as he should) that a "read(fd,...)==0" after a select(2) call that indicated activity on fd means that the other side has closed the connection. Alas - I think that I've just read not long ago that there is a bug in Linux' select in implementing just that and it might miss the close from the other side sometimes (sorry, can't find a reference with a quick google, closest I got to might be: http://forum.java.sun.com/thread.jspa?threadID=767657 <http://forum.java.sun.com/thread.jspa?threadID=767657&messageID=4386218 > &messageID=4386218). I don't remember what was the work-around to that. Another point to check - does the read(2) after select(2) return an error? See select_tut(2) for more details on how to program with select - you should check for errors as well instead of just assuming that read(2) must succeed ( e.g. interrupt). Also while you are at it - check whether pselect(2) can help you improve your program's robustness. Maybe using poll(2) will help you around that (I also heard that poll is generally more efficient because it helps the kernel avoid having to re-interpret the syscall parameters on every call). --Amos
