I'm trying to have a listener socket, upon receiving a connection it will proceed the request in an actor(messing with smtp).

I've done it and it works fairly well but the issue I have is as follow:

• In theory I don't want to set a timeout on the socket, or at least not a short one.
• In the actor i read from the socket "in" "forever"

In the main service i try to find when the socket is closed ... but even when i close it from the client side (testing using telnet), it doesn't detect it a closed. The in.readBuf in the actor does not stop either (unless you wait for the timeout)

It seems the readBuf is locking the socket and preventing socket.isConnected from working properly, alternative readBuf() should probably stop/terminate if the socket was closed.

Because of those combined behaviors I can't find a proper solution that works well.

Here is some of the relevant code I'm messing with: http://pastebin.com/raw.php?i=iTTqQaKF

Is there a way i can properly detect the socket instream is closed and/or having readBuf stop waiting if the stream has been closed on the other end ?

Note: running this on OSX if it makes any difference.

If you close a socket, then pretty much all the Java I/O methods will throw an exception (which turns into a Fantom sys::IOErr).

Where in that code do you close the actual server socket? I see where you close the listener, but not the socket returned by each accept.

i'm connecting via telnet to it (telnet is the "client")

when I quit telnet it does not disconnect and doesn't throw an exception either on in.readBuf (until the timeout)

So in other words I'm closing the socket from the client side ... I expect that to be detected and/or throw an error on the server side, no ?

So in other words I'm closing the socket from the client side ... I expect that to be detected and/or throw an error on the server side, no ?

Sometimes that will work, but often not. That is just the way sockets work. TCP has its own keep alive mechanism that will sometimes detect this, or you timeout on a read. A good protocol often has explicit closing messaging to cleanup gracefully.

If you really want to dig into it you can put some printlns where Fantom calls the underlying Java InputStream read - its probably just blocking there until the timeout occurs.

OK thanks .... unfortunately SMTP is not a great protocol.

Thanks.

I guess I get to do my own "hearbeat" stuff using NOOP ... that should work