Correct, I won't use auto keep alive transmission. Thanks Gavin.

On Mon, Feb 27, 2017 at 8:49 AM, Gavin Lambert via Boost-users <boost-users@lists.boost.org> wrote:
On 25/02/2017 09:33, jupiter via Boost-users wrote:
Yes, I am also writhe the client program, each client has an unique
identification and provides expecting only one connection per client.
The client will auto-reconnect to the server if it detect lost
connection, the question again, is writing to boost::asio::write the
efficient way to detect a stalled connection or  are there any better
alternatives to get feedback from the boost::asio::ip::tcp::socket
lowest_layer? The problem is the client is always waiting receiving from
server, if the client cannot detect from the oost::asio::ip::tcp::socket
while waiting on boost::asio::read, then I have to run constantly
heartbeat in every second or so which I try to avoid too much
unnecessary bandwidth usage as the client is replying on LTE
transmission, network bandwidth cost needs be considered.

As I understand it, the way that TCP itself works requires a transmission to detect a disconnected peer.

I haven't looked into how it's exposed in ASIO, but the sockopt I mentioned before is SO_KEEPALIVE -- it's basically just an automated periodic transmission.  A slight advantage of this over explicit writes is that the payload is a lot smaller, but it's still a packet.

If the client is expected to be using mobile Internet then to conserve both bandwidth and battery life you probably should not use any sort of keep-alive transmissions.  Instead design your server and protocol to expect that it won't really know how many clients are "really" connected at any given moment, and only discard a connection when you either have a fresh incoming one from the same client or if you failed to transmit.



_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users