On 15/05/07, guy keren <[EMAIL PROTECTED]> wrote:
> I think you are tinkering with semantics and so miss the real issue (do > you work as a consultant? :). did you write that to rafi or to me? i'm not dealing with semantics - i am dealing with a real problem, that stable applications have to deal with - when the network breaks, and you never get the close from the other side.
I wrote this to you, Guy. Rafi maybe used "disconnect" when he basically ment that the TCP connection went down from the other side while you seemed to hang on "disconnect" being defined as "cable eaten by an aligator" :). As long as Rafi feels happy about the replies that's not relevant any more, IMHO.
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 what you are describing here sounds astonishing - that such a basic feature of the sockets implementation is broken? i find this hard to believe, without clear evidence.
Here is something about what I read before, it's the other way around, and possibly only relevant to UDP but I'm not sure - if a packet arrives with bad CRC, it's possible that the FD will be marked as "ready to read" by select but then the packet will be discarded (because of the CRC error) and when the process reads the socket it won't get anything. That would make the process get a "0 read right after select" which does NOT indicate a close from the other side. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0410.2/0001.html I don't know what would be a select(2)-based work-around, if required at all.
(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&messageID=4386218 > <http://forum.java.sun.com/thread.jspa?threadID=767657&messageID=4386218 >). > I don't remember what was the work-around to that. you're describing an issue with JVM - not with linux. i never encountered such a problem when doing socket programming in C or C++. if you can find something clearer about this, that will be very interesting.
Yes, it was a JVM bug but it mentioned differences on Linux vs. other POSIX systems so I though it might be related. it helps avoiding copying too much data to/from kernel space on a sparse
sockets list, and it helps avoiding having to scan large sets in the kernel, to initialize its onw internal data structures.
Actually, epoll looks really cool, and Boost's ASIO seems to provide a portable C++ interface around it: http://asio.sourceforge.net/ On the other hand - if you are listening on many FD's which turn out to be ready then epoll apparently looses because it requires syscall (or kernel intervention) on every single FD, making select(2) (/poll(2)?) more attractive. Cheers, --Amos
