Amos Shapira wrote:
On 14/05/07, *guy keren* <[EMAIL PROTECTED] <mailto:[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? :).
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.
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.
if this is what he expects than, indeed, this is what happens.
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.
(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.
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).
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.
--guy
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
