[erlang-questions] ssl_closed not always received

[Khitai Pang]

On 2016/4/11 21:43, Fred Hebert wrote:
> 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.

Great information!  However, heartbeat messages seem to be necessary 
evil.  I will try 5-min heartbeat.

I also heard that when sending a message, keep the message as small as 
possible, because the bigger the message is, the higher power rate the 
antenna gets raised to and the longer time it keeps the power rate.


Thanks
Khitai