how to know if socket is still connected

N

nephish

lo there,
i have a simple app that connects to a socket to get info from a server

i looks like this

serverhost = 'xxx.xxx.xxx.xxx'
serverport = 9520
aeris_sockobj = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
aeris_sockobj.connect((serverhost,serverport))

while 1:
do this or that with socket,
send and receive info.
yadda yadda yadda


works well, but sometimes the server drops the connection.
so, what i need is something that will let me know if the connection
is still ok, if not will reconnect.

what i thought, since it only lets you connect on a certain port one at
a time,
that i could use a try-except to connect every time, if it could not
connect (because it already is) then i would just continue on. But if
it is not connected, it would reconnect.
that is what brings me here. Seems like it would work, but is there a
better way ? this kinda seems like a dirty hack.

any opinions ?

thanks.
 
G

Grant Edwards

serverhost = 'xxx.xxx.xxx.xxx'
serverport = 9520
aeris_sockobj = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
aeris_sockobj.connect((serverhost,serverport))

while 1:
do this or that with socket,
send and receive info.
yadda yadda yadda

works well, but sometimes the server drops the connection. so,
what i need is something that will let me know if the
connection is still ok, if not will reconnect.

If the server has closed the connection, then a recv() on the
socket will return an empty string "", and a send() on the
socket will raise an exception.
what i thought, since it only lets you connect on a certain
port one at a time, that i could use a try-except to connect
every time, if it could not connect (because it already is)
then i would just continue on. But if it is not connected, it
would reconnect. that is what brings me here. Seems like it
would work, but is there a better way?

I don't see why the normal send() and recv() semantics aren't
sufficient.
 
N

nephish

Grant said:
If the server has closed the connection, then a recv() on the
socket will return an empty string "", and a send() on the
socket will raise an exception.


I don't see why the normal send() and recv() semantics aren't
sufficient.



like this ?
databack = aeris_sockobj.recv(2048)
if databack:
view_msg = 'caught request acknowlage %s bytes \n' %
len(databack)
else:
view_msg = 'fail to recieve data from aeris server\n'

then put the reconnect in the else: block ?

thanks


thanks
 
G

Grant Edwards

like this ?
databack = aeris_sockobj.recv(2048)
if databack:
view_msg = 'caught request acknowlage %s bytes \n' %
len(databack)
else:
view_msg = 'fail to recieve data from aeris server\n'

then put the reconnect in the else: block ?

Yes, if the problem is that the host closes the connection,
that should work. Modulo the broken indentation and
line-wrapping. ;)
 
N

nephish

cool enough, thanks !

-sk


Grant said:
Yes, if the problem is that the host closes the connection,
that should work. Modulo the broken indentation and
line-wrapping. ;)
 
C

Cameron Laird

If the server has closed the connection, then a recv() on the
socket will return an empty string "", and a send() on the
socket will raise an exception.


I don't see why the normal send() and recv() semantics aren't
sufficient.
.
.
.
Often normal send() and recv() semantics have been mistaught.
An alert alien, looking at other common APIs in isolation,
might reasonably wonder whether there is some sort of
still_ok_to_use() sort of check as part of TCP. As it happens,
of course, that doesn't fit with the rest of socket networking,
which takes the "modernist" approach of trying send() or recv(),
and reporting any exception.
 
G

Grant Edwards

.
.
.
Often normal send() and recv() semantics have been mistaught.
An alert alien, looking at other common APIs in isolation,
might reasonably wonder whether there is some sort of
still_ok_to_use() sort of check as part of TCP. As it happens,
of course, that doesn't fit with the rest of socket networking,
which takes the "modernist" approach of trying send() or recv(),
and reporting any exception.

On most Unices there are some obscure API features that can be
used to generate a SIGPIPE under some vaguely specified error
conditions (e.g. TCP keepalive timeout). I've only read about
them and never tried to use them, since I couldn't see anything
in the description of the features that was any benefit over
the nomral send() and recv() usage.
 
N

nephish

hey there, i have a question about this solution.
if i have a
message = socket.recv()
in the script, and the socket connection drops, will the
socket.recv() just wait forever for something to come across
the internet port? or will it know if the connection is dropped?
thanks.
-sk
 
G

Grant Edwards

hey there, i have a question about this solution.
if i have a
message = socket.recv()
in the script, and the socket connection drops, will the
socket.recv() just wait forever for something to come across
the internet port? or will it know if the connection is dropped?

As I said before, if the socket is closed by the remote host,
recv() will return "".

I don't know what you mean by "drops" and "dropped" in this
context. If you want a useful answer to your question, you'll
have to define your terms precisely.
 
N

nephish

oh, sorry, what i mean by dropped is that the server i am connecting to
can close the connection. If that happens, i need to know about it.
i also need to know about it if the server i am connecting to just
dies.

if recv() returns "" is that the same as NONE ?
again, sorry, i am still kinda new at this.
I mean can the value be tested true or false?

thanks
-sk
 
G

Grant Edwards

oh, sorry, what i mean by dropped is that the server i am
connecting to can close the connection.

Then recv() will return "" and send() will raise an exception.
If that happens, i need to know about it. i also need to know
about it if the server i am connecting to just dies.

Again, you have to define what you mean by "server just dies".

If the server _application_ crashes or exits, then the OS will
close the socket and recv() will return "". If somebody powers
down the server without warning, or if the server OS crashes,
or if the Ethernet cable between the Internet and the server is
cut, then the socket will not be closed, and recv() will wait
forever[1].
if recv() returns "" is that the same as NONE ?

No. It's the empty string (also spelt '').
I mean can the value be tested true or false?

Yes. The empty string is false, all non-empty strings are
true.

[1] Unless you've enabled the TCP Keepalive feature, in which
case the socket will timeout in a couple hours and recv()
will return "".
 
N

nephish

If the server _application_ crashes or exits, then the OS will
close the socket and recv() will return "". If somebody powers
down the server without warning, or if the server OS crashes,
or if the Ethernet cable between the Internet and the server is
cut, then the socket will not be closed, and recv() will wait
forever[1].

Ok, yes all of the above is what i mean. Actually I am not too
concerned about a server os crash, or the cable being cut. But I have
had them close the connection on me, after which i just reconnect
(whenever i discover that its happened)
[1] Unless you've enabled the TCP Keepalive feature, in which
case the socket will timeout in a couple hours and recv()
will return "".

if this is something that must be enabled, or is not enabled by
default, then it is not enabled.
so i should be pretty good.

thanks for all of your help, gents !
-sk




Grant said:
oh, sorry, what i mean by dropped is that the server i am
connecting to can close the connection.

Then recv() will return "" and send() will raise an exception.
If that happens, i need to know about it. i also need to know
about it if the server i am connecting to just dies.

Again, you have to define what you mean by "server just dies".

If the server _application_ crashes or exits, then the OS will
close the socket and recv() will return "". If somebody powers
down the server without warning, or if the server OS crashes,
or if the Ethernet cable between the Internet and the server is
cut, then the socket will not be closed, and recv() will wait
forever[1].
if recv() returns "" is that the same as NONE ?

No. It's the empty string (also spelt '').
I mean can the value be tested true or false?

Yes. The empty string is false, all non-empty strings are
true.

[1] Unless you've enabled the TCP Keepalive feature, in which
case the socket will timeout in a couple hours and recv()
will return "".
 
G

Grant Edwards

If the server _application_ crashes or exits, then the OS will
close the socket and recv() will return "". If somebody powers
down the server without warning, or if the server OS crashes,
or if the Ethernet cable between the Internet and the server is
cut, then the socket will not be closed, and recv() will wait
forever[1].

Ok, yes all of the above is what i mean. Actually I am not too
concerned about a server os crash, or the cable being cut. But I have
had them close the connection on me, after which i just reconnect
(whenever i discover that its happened)
[1] Unless you've enabled the TCP Keepalive feature, in which
case the socket will timeout in a couple hours and recv()
will return "".

if this is something that must be enabled, or is not enabled by
default, then it is not enabled.

On all OSes with which I'm familiar it's disabled by default.
You use a socket object's setsockopt method to enable it:

s.setsockopt(socket.SOL_TCP,socket.SO_KEEPALIVE,True)
 
N

nephish

ok, yeah, thats in my book.
thanks, and no, it isn't enabled.
thanks again for everything
-sk


Grant said:
If the server _application_ crashes or exits, then the OS will
close the socket and recv() will return "". If somebody powers
down the server without warning, or if the server OS crashes,
or if the Ethernet cable between the Internet and the server is
cut, then the socket will not be closed, and recv() will wait
forever[1].

Ok, yes all of the above is what i mean. Actually I am not too
concerned about a server os crash, or the cable being cut. But I have
had them close the connection on me, after which i just reconnect
(whenever i discover that its happened)
[1] Unless you've enabled the TCP Keepalive feature, in which
case the socket will timeout in a couple hours and recv()
will return "".

if this is something that must be enabled, or is not enabled by
default, then it is not enabled.

On all OSes with which I'm familiar it's disabled by default.
You use a socket object's setsockopt method to enable it:

s.setsockopt(socket.SOL_TCP,socket.SO_KEEPALIVE,True)
 
L

Laszlo Nagy

(e-mail address removed) írta:
ok, yeah, thats in my book.
thanks, and no, it isn't enabled.
thanks again for everything
-sk
Another hint: use select.select() on the socket before reading. It will
tell you if recv() will block or not. This way you can implement your
own async timeout and do something else in your program while waiting
for the connection to be available.

Best,

Laszlo
 
J

John J. Lee

Grant Edwards said:
On most Unices there are some obscure API features that can be
used to generate a SIGPIPE under some vaguely specified error
conditions (e.g. TCP keepalive timeout). I've only read about
them and never tried to use them, since I couldn't see anything
in the description of the features that was any benefit over
the nomral send() and recv() usage.

Sorry for butting in, Grant, but this reminds me of this bug:

http://python.org/sf/1411097


and specifically, of my question in the tracker:

| One problem: I don't understand the need for
| HTTPConnection._safe_read(), rather than checking for an
| EINTR resulting from the recv() call (or WSAEINTR on
| Windows). Can anybody explain that?


Note the comment in the third paragraph in the method's docstring,
below ("Note that we cannot...", and the "if not chunk" test). Do you
know of any reason why it should do that (fail to check for EINTR)?
Looks wrong to me.

(I do understand that it's only signals that arrive before *any* data
is read that cause EINTR, but that's the specific case mentioned in
the 3rd para, and a check for that is what's conspicuously absent from
the method implementation.)

def _safe_read(self, amt):
"""Read the number of bytes requested, compensating for partial reads.

Normally, we have a blocking socket, but a read() can be interrupted
by a signal (resulting in a partial read).

Note that we cannot distinguish between EOF and an interrupt when zero
bytes have been read. IncompleteRead() will be raised in this
situation.

This function should be used when <amt> bytes "should" be present for
reading. If the bytes are truly not available (due to EOF), then the
IncompleteRead exception can be used to detect the problem.
"""
s = []
while amt > 0:
chunk = self.fp.read(min(amt, MAXAMOUNT))
if not chunk:
raise IncompleteRead(s)
s.append(chunk)
amt -= len(chunk)
return ''.join(s)


John
 
B

bryanjugglercryptographer

Grant said:
If the server has closed the connection, then a recv() on the
socket will return an empty string "",

after returning all the data the remote side had sent, of course.
and a send() on the
socket will raise an exception.

Send() might, and in many cases should, raise an exception
after the remote side has closed the connection, but the behavior
is unreliable.
 
L

Lawrence D'Oliveiro

If the server has closed the connection, then a recv() on the
socket will return an empty string "", and a send() on the
socket will raise an exception.

Would that still apply when trying to send an empty string?
 
S

Steve Holden

Lawrence said:
Would that still apply when trying to send an empty string?

Yes: sending an empty string demands no action on the server's part, as
the receiver has already received it ... adding an empty string to
whatever the sender currently has buffered does not require any state
change on the sender's part.

regards
Steve
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top