[erlang-questions] ssl_closed not always received
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.
Author of The Erlanger Playbook,
A book about software development using Erlang
More information about the erlang-questions