[erlang-questions] ssl_closed not always received

[Khitai Pang]

On 2016/4/11 17:52, Loïc Hoguin wrote:
> 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 match.

By non-matching timeouts on client an server do you mean that we should 
give some grace time to the client? e.g. the client sends a message 
every 5 minutes but the server deems the connection as lost if no 
message is received in 6 minutes?

Thanks
Khitai

> 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.