How to detect physical TCP/IP desconnection
George Wilkin
(with recv()). And I need to detect in client when something abnormal
happens to the server (physical ethernet cable disconnection, PC power
shutdown, etc..).
I.e., when I terminate the Server process (in task manager), there is no
problem, and client knows about this, because its recv() call fails, but I
suppose that it is because the server process' socket is closed by OS at
that moment. But when I suddenly switch off the server's PC, or switch off
the hub, or disconnect the server net cable, client's recv() doesnt fail(!)
and client continues waiting for the data to arrive. So how can this
physical failure be detected?
Thank you.
Alex Fraser
"George Wilkin" <g...@dontspam.com> wrote in message
news:b93vml$dh7$1...@nsnmpen2-gest.nuria.telefonica-data.net...
> Hello, I have a program Client receives some data from Server by TCP/IP
> (with recv()). And I need to detect in client when something abnormal
> happens to the server (physical ethernet cable disconnection, PC power
> shutdown, etc..).
[snip]
The only reliable method is to timeout the receive operation. To guarantee
you don't get stuck in recv(), you must use non-blocking sockets. You can
then use select() (or WSA*Select() and related functions) with the socket to
block until you should call send()/recv() or the timeout is reached.
Alex
George Wilkin
a recv() call, that sometimes receives data (when server sends it), but it
is not receiving continuously, and there can be an interval up to several
minutes between two sends.
So is there any way to check periodically (in client) that the server socket
is still "alive"? (that the server PC is working)?
Or another approach, is there a way to make this recv() call return error
immediately, when detecting that the server has broken?
Thank you,
Ger.
Hector Santos
or SOCKET_ERROR value. From the docs:
Return Values:
If no error occurs, recv returns the number of bytes received. If the
connection has been gracefully closed, the return value is zero. Otherwise,
a value of SOCKET_ERROR is returned, and a specific error code can be
retrieved by calling WSAGetLastError.
You can also use the select() command to detect when data is available
before calling recv(). select() will return a SOCKET_ERROR if the socket is
closed.
---
"George Wilkin" <g...@dontspam.com> wrote in message
news:b944hi$5i4$1...@nsnmpen2-gest.nuria.telefonica-data.net...
Alex Fraser
> Thank you, but my client application has a separate thread and inside it
> has a recv() call, that sometimes receives data (when server sends it),
> but it is not receiving continuously, and there can be an interval up to
> several minutes between two sends.
> So is there any way to check periodically (in client) that the server
> socket is still "alive"? (that the server PC is working)?
Yes, periodically send something; if you get a reply then you can be sure
the connection and server were working for some period between the time you
sent and the time you received. More useful than it sounds :).
> Or another approach, is there a way to make this recv() call return error
> immediately, when detecting that the server has broken?
No. If you're only receiving, there may never be notification (of ANY sort,
not just notification by Winsock to your application) that anything has
happened. Instead of detecting the presence of failure, you must presume
it - detect the absence of success with a timeout.
Alex
Alex Fraser
"Alex Fraser" <m...@privacy.net> wrote in message
news:b94cvk$fe33d$1...@ID-149533.news.dfncis.de...
> "George Wilkin" <g...@dontspam.com> wrote in message
> news:b944hi$5i4$1...@nsnmpen2-gest.nuria.telefonica-data.net...
[snip]
> > So is there any way to check periodically (in client) that the server
> > socket is still "alive"? (that the server PC is working)?
>
> Yes, periodically send something [...]
As an example, have a look at what IRC servers do to detect defunct clients.
> > Or another approach, is there a way to make this recv() call return
> > error immediately, when detecting that the server has broken?
>
> No. If you're only receiving, there may never be notification (of ANY
> sort, not just notification by Winsock to your application) that anything
> has happened. [...]
Note that if you are sending, but the data is not acknowledged soon enough
by the remote host (server in this case), the connection will detectably
fail. This is not a guarantee that the server has received the data, only
the server can tell you that. (There is of course the unavoidable problem
that the server might have received it, but you never receive the
acknowledgement.)
Alex
Przemek Wasylko
> Hello, I have a program Client receives some data from Server by TCP/IP
> (with recv()). And I need to detect in client when something abnormal
> happens to the server (physical ethernet cable disconnection, PC power
> shutdown, etc..).
I would suggest:
1. Use recv() / send() with programmed timeouts
2. getsockopt() with SO_CONNECT_TIME parameter. When connection is dead, it
will return 0.
Przemek Wasylko
> news:b93vml$dh7$1...@nsnmpen2-gest.nuria.telefonica-data.net...
> > Hello, I have a program Client receives some data from Server by
> > TCP/IP (with recv()). And I need to detect in client when something
> > abnormal happens to the server (physical ethernet cable
> > disconnection, PC power shutdown, etc..).
>
I would suggest:
arkadyf
established and that
possible only through some keep-alive scenario as advised , additionally ,
disconnection
on this computer possible to check with some of the methods described on
http://www.ndis.com/faq/QA01050301
Arkady
"Przemek Wasylko" <was...@removeme.clubbing.pl> wrote in message
news:#9l0dwtE...@TK2MSFTNGP12.phx.gbl...
David Schwartz
> Thank you, but my client application has a separate thread and inside it
has
> a recv() call, that sometimes receives data (when server sends it), but it
> is not receiving continuously, and there can be an interval up to several
> minutes between two sends.
> So is there any way to check periodically (in client) that the server
socket
> is still "alive"? (that the server PC is working)?
> Or another approach, is there a way to make this recv() call return error
> immediately, when detecting that the server has broken?
If you could detect an error if the connection was broken for only a
split second, every network hiccup would break your connection. TCP is
specifically designed to be resilient to network outages.
DS
John Smith
client can send to the server harmlessly. If the computer hosting the
service is alive, and the service is alive, an ACK will be sent, and
everything will be fine at the TCP layer. However, if the computer is
non-reachable at that time, for whatever reason (cut wire/crashed
server/etc), the client side will eventually (in short order) give up the
ghost on the connection, and your recv should then fail.
--
Tom
"arkadyf" <ark...@hotmail.com> wrote in message
news:%23Lpil2u...@TK2MSFTNGP12.phx.gbl...
George Wilkin
int i = 1;
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (const char*) &i, sizeof i))
but nothing changes, i.e., when I disconnect net cable in server, client's
RECV() calls never
returns and keeps waiting for data(???).
Thank you.
Phil Frisbie, Jr.
The socket option SO_KEEPALIVE was depreciated even as it was originally added
to the TCP spec! The default time-out value is two hours before sending the
keepalive message. And the time-out is global, so changing it affects all
applications on your computer.
If you need to quickly know when the connection is broken then you should add
this to your protocol. Simply sending your own own keepalive message when no
messages have been received will do what you want. That way you can determine
the time-out and even alter it on the fly.
> Thank you.
--
Phil Frisbie, Jr.
Hawk Software
http://www.hawksoft.com
Tom Stewart
There is a registry value that governs this timeout, but as Phil says, it is
global, and it may not work on all platforms going back (like 95). That's
why we did our own.
--
Tom
"Phil Frisbie, Jr." <ph...@hawksoft.com> wrote in message
news:3EB6A7B4...@hawksoft.com...
arkadyf
But SO_CONNECT_TIME doesn't exist in winsock maybe that's the feature of
Unix Oses ?
Arkady
"Przemek Wasylko" <was...@removeme.clubbing.pl> wrote in message
news:#9l0dwtE...@TK2MSFTNGP12.phx.gbl...
arkadyf
HKLM\System\CurrentControlSet\Services\Tcpip\Parameters
Arkady
"Tom Stewart" <tast...@msdn.microsoft.com> wrote in message
news:O$o8sxzED...@TK2MSFTNGP12.phx.gbl...
George Pavlenko
> Przemek !
> But SO_CONNECT_TIME doesn't exist in winsock maybe that's the feature of
> Unix Oses ?
I use
1) select
2) recv
(in this order)
if socket is ready for reading or dropped "select" terminates it's
waiting and then I call "recv" and if socket is on-line the function
reads bytes, another way - it returns error...
arkadyf
Arkady
"George Pavlenko" <em...@teleport.kiev.ua> wrote in message
news:b989vo$6jl$1...@news.dg.net.ua...
SenderX
> That's OK , but my problem , that I cannot find SO_CONNECT_TIME
> Arkady
#include <MSWSock.h>