Re: Socket Infinitely Readable, Not EOF

Uwe Klein wrote:

> Melissa Schrumpf wrote:
>
> > ...repeats forever. These sockets are fconfigure -translation binary
> > -encoding binary -buffering none -blocking 0 on both ends (the other end
> > of the socket is another Tcl process, and have not closed), and
> > ::blockSz is set to something like 10k.

> You are bitten by "-blocking 0" on the read_socket ( i think ...).
> Actually fileevent is an _alternate_ to working with "-blocking 0" .

Yes, non-blocking on the readable event appears to be the problem.
I wouldn't say fileevent is strictly an alternate to non-blocking.

The point of fileevent, as I understand it, is that

1. blocking channels don't need to block forever just waiting for
data to become available.

2. non-blocking channels don't need to use a "polling" loop

I suppose what I could do is try setting the socket blocking,
set it non-blocking when I need to do the read, and set it blocking
again before the readable handler exits.



What I'm thinking may be going on here is issues at the TCP level.

I'll need to confirm this with a `tcpdump,` but my suspicion is
that perhaps this is caused by some issue with FIN/ACK? Perhaps
it is not getting transmitted properly?

Understandably, if a TCP socket is not closed properly, according
to TCP, there is no way for the process to know that the remote
end has closed, until it attempts to write the socket. Which, in
this case, won't happen, because there is nothing to write.

Still, it seems odd that this seems to happen in "bursts" -- that
new sockets succumb to the same problem when they are opened.

Related question, since I don't have my BSD book handy: is it the
OS or the application that causes the TCP connection to be closed?
That is, if the application properly closes a socket, obviously
all the underlying TCP messages are queued up. What happens if
the process gets one of the various SIGnals? Does the OS close
the socket without "cleaning up," and thus the remote end of a
socket may not receive any indication, and will have to wait
sufficiently long for the socket to time out?


> When fileevent triggers it is accertained that either data is readable
> or the stream is at the end ( EOF ).

Right, the problem here is that there is no data, and [eof] is returning
0.


> the event_handler should read once, process and return.

> There is no need to _unhandle_ the fileevents.
> Just close the sockets and the eventhandler will be dropped as well.

I thought that, but wasn't certain. Thanks.

--
MKS
.