Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
Hi,

The asio tcp server can detect the disconnection when the client program stop. But I have small device when it lost power, the server won't be able to detect the TCP disconnection. Does the boost socket has TCP timeout? What is an effective way to handle this situation other than running heartbeat in user level?

Thank you.

Kind regards,

- j

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
On 06/29/2017 06:28 AM, jupiter via Boost-users wrote:

> Hi,
>
> The asio tcp server can detect the disconnection when the client program
> stop. But I have small device when it lost power, the server won't be able
> to detect the TCP disconnection. Does the boost socket has TCP timeout?
> What is an effective way to handle this situation other than running
> heartbeat in user level?
>
> Thank you.
>
> Kind regards,
>
> - j
>

Well, you could always activate TCP keepalive via socket options
and set the corresponding timeout and interval values accordingly.

However, it depends on what you want to do really:
The TCP keepalive mechanism is something that is implemented by the TCP
stack of the operating system
and will only check whether the connection is still alive, but that may
not be enough because
it won't check whether the service you're connected to is actually
working/responding.
And this is where the application layer heartbeat comes back in.

Hope this gives you some idea.

Regards,
Andreas

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
Thanks for the response.

The server program is calling boost::asio::async_read for waiting for client's data, I am wondering why the async_read didn't fire an error when the remote socket connection is gone. I thought that boost::asio::async_read should detect lost connection. The fact is it does in most of the situations when the client program is ended, but it cannot detect when the client device suddenly lost power connection, I think that might because TCP only send syn / ack during connection / disconnection, the syn/ack would not be active after establishing the connection, correct me if I am wrong here.

You are right, if I have to use keep alive, I'll use it in user level which could better control the time and use less bandwidth than the system keep alive.

Thank you.

Kind regards,

- j

On Thu, Jun 29, 2017 at 3:09 PM, Andreas Wehrmann via Boost-users <[hidden email]> wrote:
On 06/29/2017 06:28 AM, jupiter via Boost-users wrote:
Hi,

The asio tcp server can detect the disconnection when the client program
stop. But I have small device when it lost power, the server won't be able
to detect the TCP disconnection. Does the boost socket has TCP timeout?
What is an effective way to handle this situation other than running
heartbeat in user level?

Thank you.

Kind regards,

- j


Well, you could always activate TCP keepalive via socket options
and set the corresponding timeout and interval values accordingly.

However, it depends on what you want to do really:
The TCP keepalive mechanism is something that is implemented by the TCP stack of the operating system
and will only check whether the connection is still alive, but that may not be enough because
it won't check whether the service you're connected to is actually working/responding.
And this is where the application layer heartbeat comes back in.

Hope this gives you some idea.

Regards,
Andreas

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
On 06/29/2017 09:01 AM, jupiter wrote:

> Thanks for the response.
>
> The server program is calling boost::asio::async_read for waiting for
> client's data, I am wondering why the async_read didn't fire an error when
> the remote socket connection is gone. I thought that
> boost::asio::async_read should detect lost connection. The fact is it does
> in most of the situations when the client program is ended, but it cannot
> detect when the client device suddenly lost power connection, I think that
> might because TCP only send syn / ack during connection / disconnection,
> the syn/ack would not be active after establishing the connection, correct
> me if I am wrong here.
>
> You are right, if I have to use keep alive, I'll use it in user level which
> could better control the time and use less bandwidth than the system keep
> alive.
>
> Thank you.
>
> Kind regards,
>
> - j
>
>

The TCP connection is usually managed by your operating system (the TCP
stack of it, to be precise).
When your application suddenly ends or crashes, the operating system
will clean up the TCP connections for you (i.e disconnect them)
which is the reason why the other end sees an "immediate" disconnect in
this case.
Tearing down a connection involves specific signalling on the TCP layer
(FIN,RST).

Now imagine your situation:
You have two machines, and both have a TCP connection to each other.
When the TCP connection is idle (i.e. nothing is sent between the two)
there won't be any signalling on the TCP layer
if TCP keep-alive is disabled and there is no application layer
heartbeat mechanism.

You might already see the problem here: In this situation you won't ever
detect whether the other machine is gone,
if it suddenly disappeared (i.e. sudden power loss, or some kind of
network problem) because:
Disconnecting a TCP session or detecting presence always requires some
kind of signalling.

So, you might already see that this is not a problem specific to asio
but to TCP sockets in general.

Regards,
Andreas

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
* Andreas Wehrmann via Boost-users <[hidden email]> [2017-06-29 09:18+0200]

> On 06/29/2017 09:01 AM, jupiter wrote:
> >Thanks for the response.
> >
> >The server program is calling boost::asio::async_read for waiting for
> >client's data, I am wondering why the async_read didn't fire an error when
> >the remote socket connection is gone. I thought that
> >boost::asio::async_read should detect lost connection. The fact is it does
> >in most of the situations when the client program is ended, but it cannot
> >detect when the client device suddenly lost power connection, I think that
> >might because TCP only send syn / ack during connection / disconnection,
> >the syn/ack would not be active after establishing the connection, correct
> >me if I am wrong here.
> >
> >You are right, if I have to use keep alive, I'll use it in user level which
> >could better control the time and use less bandwidth than the system keep
> >alive.
> >
> >Thank you.
> >
> >Kind regards,
> >
> >- j
> >
> >
>
> The TCP connection is usually managed by your operating system (the TCP
> stack of it, to be precise).
> When your application suddenly ends or crashes, the operating system will
> clean up the TCP connections for you (i.e disconnect them)
> which is the reason why the other end sees an "immediate" disconnect in this
> case.
> Tearing down a connection involves specific signalling on the TCP layer
> (FIN,RST).
>
> Now imagine your situation:
> You have two machines, and both have a TCP connection to each other.
> When the TCP connection is idle (i.e. nothing is sent between the two) there
> won't be any signalling on the TCP layer
> if TCP keep-alive is disabled and there is no application layer heartbeat
> mechanism.

Implied but not stated here: a TCP keep-alive would be sufficient to
notify a server about a client falling off the net, though you may
have other reasons to want your own heartbeat messages.


> You might already see the problem here: In this situation you won't ever
> detect whether the other machine is gone,
> if it suddenly disappeared (i.e. sudden power loss, or some kind of network
> problem) because:
> Disconnecting a TCP session or detecting presence always requires some kind
> of signalling.
>
> So, you might already see that this is not a problem specific to asio but to
> TCP sockets in general.
>
> Regards,
> Andreas
>
> _______________________________________________
> Boost-users mailing list
> [hidden email]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users

--
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

([hidden email])
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list


On Thu, Jun 29, 2017 at 5:50 PM, Eric Prud'hommeaux <[hidden email]> wrote:
> Tearing down a connection involves specific signalling on the TCP layer
> (FIN,RST).
>
> Now imagine your situation:
> You have two machines, and both have a TCP connection to each other.
> When the TCP connection is idle (i.e. nothing is sent between the two) there
> won't be any signalling on the TCP layer
> if TCP keep-alive is disabled and there is no application layer heartbeat
> mechanism.

Implied but not stated here: a TCP keep-alive would be sufficient to
notify a server about a client falling off the net, though you may
have other reasons to want your own heartbeat messages.


I have a connection map in my server as part of monitoring system to trace down the client connections. If the server can be notified by kernel for a client falling off, that will be
good to use a callback errorHandler to clean up the socket connection as well as the connection map automatically.

Bandwidth usage is another restriction in my application as the small devices connect by 3G / LTE, anyone knows what is the extra package size for using boost keep alive option?

If I have to use heartbeat in user level, I also need deploy a timer / polling mechanism in the server to check missing heartbeat messages then clear the connection and connection map. I don't mind if a client is in idle, but the monitoring system need to detect if a client is connected or not. I don't feel understanding boost socket keepalive option well, I need to explore the boost socket keepalive option more.






_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
jupiter via Boost-users 2017-06-29 15:41:

Hi,

> I have a connection map in my server as part of monitoring system to
> trace
> down the client connections. If the server can be notified by kernel
> for a
> client falling off, that will be
> good to use a callback errorHandler to clean up the socket connection
> as
> well as the connection map automatically.

You should inherit the enable_shared_from_this<your session class>, and
in async ops in your session class you should use shared_from_this()
when start async ops.

For monitoring your session you should use map/any_container with
weak_ptrs, not shared_ptrs.


--
Regards, niXman
___________________________________________________
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
https://sf.net/p/mingw-w64/
_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list


On Thu, Jun 29, 2017 at 10:51 PM, niXman via Boost-users <[hidden email]> wrote:

You should inherit the enable_shared_from_this<your session class>, and in async ops in your session class you should use shared_from_this() when start async ops.

Yes, I did.

For monitoring your session you should use map/any_container with weak_ptrs, not shared_ptrs.

Interesting, I haven't thought that, what will be the issues and consequences to use shared_ptrs not weak_ptrs? Thanks for your advice.


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list

For monitoring your session you should use map/any_container with weak_ptrs, not shared_ptrs.

Interesting, I haven't thought that, what will be the issues and consequences to use shared_ptrs not weak_ptrs? Thanks for your advice.
Shared pointers keep objects in existence, weak pointers don't. At a price of an additional lock() operation, of course (which, except in really time critical applications, should not be an issue).

It's never a good idea to have too many shared pointers around, especially not in the monitoring maps as they may keep objects alive longer than intended.

Additional advantage of using weak pointer in monitoring maps is that if the lock() fails it's okay to remove the entry from the map as the object is no longer there.

Now, for the sake of being thorough - although weak pointer will not keep the object in existence, it will keep it's shared count alive. Which, in the case of using std::make_shared to allocate shared count and object memory in a single block, will keep the entire block of memory allocated until the last weak pointer is gone ... hence even in the case of using weak pointers it is a good idea to do occasional cleanup, which is rather trivial via failed lock().

Cheers,
Leon



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users



_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list


On Fri, Jun 30, 2017 at 10:31 AM, Leon Mlakar via Boost-users <[hidden email]> wrote:

For monitoring your session you should use map/any_container with weak_ptrs, not shared_ptrs.

Interesting, I haven't thought that, what will be the issues and consequences to use shared_ptrs not weak_ptrs? Thanks for your advice.
Shared pointers keep objects in existence, weak pointers don't. At a price of an additional lock() operation, of course (which, except in really time critical applications, should not be an issue).

It's never a good idea to have too many shared pointers around, especially not in the monitoring maps as they may keep objects alive longer than intended.

Additional advantage of using weak pointer in monitoring maps is that if the lock() fails it's okay to remove the entry from the map as the object is no longer there.

Now, for the sake of being thorough - although weak pointer will not keep the object in existence, it will keep it's shared count alive. Which, in the case of using std::make_shared to allocate shared count and object memory in a single block, will keep the entire block of memory allocated until the last weak pointer is gone ... hence even in the case of using weak pointers it is a good idea to do occasional cleanup, which is rather trivial via failed lock()

Thanks for the explanation, I have more work to do :-) Cheers

Cheers,
Leon


_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Why cannot asio tcp socket server detect TCP disconnection when the client device lost power?

Boost - Users mailing list
In reply to this post by Boost - Users mailing list
On Thu, 2017-06-29 at 15:51 +0300, niXman via Boost-users wrote:
> For monitoring your session you should use map/any_container with 
> weak_ptrs, not shared_ptrs.

Especially with networking code, I'd refrain from this. Though it
offers a lot of loose coupling, it makes readability difficult. For
session bring-down, I always prefer explicit "unregister()" style
messages between objects. That way, the "disconnect behaviour" is
explicitly embedded in code.

IMHO, of course :D

--
Joe Steeve
HiPro IT Solutions Private Limited
http://www.hipro.co.in/

_______________________________________________
Boost-users mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/boost-users

signature.asc (201 bytes) Download Attachment
Loading...