[erlang-questions] about socket problem

[Per Hedeland]

Rapsey <rapsey@REDACTED> wrote:
>
>That is just how sockets work I'm afraid. No matter what language you are
>using. If your server/client are on the same computer you will get a
>notification that the socket was closed, but not when  you're communicating
>over the internet. The only way around is to ping the other side every once
>in a while.

This isn't correct. There are cases of non-local TCP connections
(doesn't matter if it's over the Internet or a LAN) where there is no
notification, basically if someone pulls the power on the remote host or
pulls the wire in between, but any form of "normal" close when both
hosts keep running and the network keeps functioning will generate the
exact same notification as in the local case. UDP is a completely
different story, of course.

>On Tue, Sep 1, 2009 at 5:52 AM, Yu-Teh Shen <shenyute@REDACTED> wrote:
>>
>> After that, I kill client process, but I found out that the server didn't
>> know client was been killed!
>>
>> And I use netstat -pan in server, the connection is still exist!
>>
>> Is there anyway, the server can detect client had been killed? Like using
>> poll function in C socket (error code POLLERR or POLLHUP)

Of course this is what normally happens (modulo the case above), but it
is dependant on the behaviour of your Erlang application. If it hasn't
"expressed interest" in what happens on the socket, by using either
{active, true} or {active, once} mode, or calling gen_tcp:recv(), the VM
won't even look at it.

If the application has done either of those things, it will receive a
{tcp_closed, Socket} message or a {error, closed} return value,
respectively. (You could potentially get a {tcp_error, Socket, Reason}
message or a {error, posix()} return value instead - this shouldn't
happen when the client just closes, but you should handle it.) At this
point it is up to the application to actually close the socket by
calling gen_tcp:close().

--Per Hedeland