[erlang-questions] ssl_closed not always received

[Fred Hebert]

On 04/11, Loïc Hoguin wrote:
>On 04/11/2016 11:43 AM, Khitai Pang wrote:
>>On 2016/4/11 17:24, Loïc Hoguin wrote:
>>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?
>
> [...]
>
>So tl;dr yes, you got it right.
>

One small gotcha I'd like to add if you plan on supporting mobile users.  
A few months ago I read 'High Performance Browser Networking' by Ilya 
Grigorik, and an interesting section mentioned the usage of antennas and 
power consumption.

An interesting thing described there is the cycle of powering antennas 
in your phones up and down as data transfers are required, involvement 
of remote servers, preservation of NAT caches, and so on. Basically, the 
antenna power for 2G/3G/4G/LTE stuff will tend to be the biggest power 
source of your phone, right after screen usage. WiFi's bad, but not 
nearly as bad for the average case.

That's all okay, but the thing is that there is a thing the author calls 
the 'energy tail' that happens after each time a transmission is done:

http://i.imgur.com/7KfixDQ.png

The idea being that antenna power-up is time-based on a state machine, 
and transferring 2 kilobytes might be as significant for your battery as 
transfering 2 megabytes if they tend to mostly happen on the same 
high-energy cycle.

A very significant section of the book is this one:

> 46% of Battery Consumption to Transfer 0.2% of Total Bytes
>
> AT&T Labs Research published a great research paper ("Profiling 
> Resource Usage for Mobile Applications") in which it analyzed a 
> number of popular mobile applications for network and battery 
> efficiency. Among these applications, Pandora serves as a great case 
> study for the inefficiency of intermittent network transfers on 
> mobile networks.
>
> Whenever a Pandora user plays a song, the entire music file is 
> streamed by the application from the network in one shot, which is 
> the correct behavior: burst as much data as you can, then turn off 
> the radio for as long as possible.  However, following the music 
> transfer, the application would conduct periodic audience 
> measurements by sending intermittent analytics pings every 60 
> seconds. The net effect? The analytics beacons accounted for 0.2% of 
> the total transferred bytes and 46% of the total power consumption 
> of the application!
>
> The beacon transfers are small, but the energy tails induced by the 
> RRC state transitions were keeping the radio active for 
> significantly longer, unnecessarily wasting 46% of the battery.  By 
> coalescing the analytics data into fewer requests, or by sending the 
> audience data when the radio is already active, we can eliminate the 
> unnecessary energy tails and almost double the power efficiency of 
> the application!

(source: 
http://chimera.labs.oreilly.com/books/1230000000545/ch07.html#INEFFICIENCY_OF_PERIODIC_TRANSFERS)

The fix? Raise the timeout to at least 5 minutes; it's the shortest 
value the book recommends as mobile carriers' NAT caches tend to hold 
for 5 mins:

> Most mobile carriers set a 5–30 minute NAT connection timeout.  Hence, 
> you may need a periodic (5 minute) keepalive to keep an idle 
> connection from being dropped. If you find yourself requiring more 
> frequent keepalives, check your own server, proxy, and load balancer 
> configuration first!

(Source: 
http://chimera.labs.oreilly.com/books/1230000000545/ch08.html#ELIMINATE_POLLING) 

Regards,
Fred.