[erlang-questions] ssl_closed not always received

Loïc Hoguin essen@REDACTED
Mon Apr 11 11:52:23 CEST 2016

On 04/11/2016 11:43 AM, Khitai Pang wrote:
> On 2016/4/11 17:24, Loïc Hoguin wrote:
>> On 04/11/2016 10:23 AM, Roger Lipscombe wrote:
>>> On 10 April 2016 at 22:34, Khitai Pang <khitai.pang@REDACTED> wrote:
>>>> How to make sure that the server process always get ssl_closed when the
>>>> client process on a remote host quits?
>>> In the general case, you *can't*. This is due to the vagaries of TCP.
>>> To close a socket, the client will send a FIN packet to the server. If
>>> the network connection is lost (consider simply unplugging the cable),
>>> then the FIN will *never* arrive. If you need to know when the client
>>> has gone away, either implement some kind of application-level
>>> keepalive or enable TCP keepalive.
>> You need a bi-directional ping mechanism at the application level. TCP
>> keepalive is not always enough.
> How about this?  The client sends a heartbeat message to the server
> every 2 minutes and the server replies with a heartbeat ack.  The server
> deems the connection as lost if no heartbeat received in 2 minutes and
> the client deems the connection as lost if heartbeat ask is not received
> in 2 minutes.  This sounds like uni-directional to me but would it suffice?

All that matters is that both endpoints send a ping message. It can be 
sent as a response.

One important point is that the client and server agree on timeouts 
(this can be part of the protocol handshake or explicitly defined in the 
implementation, they just need to agree on it). Note that there's two 
timeouts: one for the client, and one for the server. They don't have to 

Using the client for sending pings (and the server just replies to 
pongs) scales better because the server only needs to keep track of one 
timeout (how long since last client message-- doesn't have to be an 
explicit ping) instead of two (the previous one + a timeout for sending 
pings). When you have one server for thousands of clients, it's usually 
better to offload processing to the clients.

So tl;dr yes, you got it right.

Loïc Hoguin
Author of The Erlanger Playbook,
A book about software development using Erlang

More information about the erlang-questions mailing list