how to know if socket is still connected

[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.

[Grant Edwards]

On 2006-07-16, ne*****@xit.net <ne*****@xit.netwrote:

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.

--
Grant Edwards grante Yow! I'm an East Side
at TYPE...
visi.com

[nephish]

Grant Edwards wrote:

On 2006-07-16, ne*****@xit.net <ne*****@xit.netwrote:

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.

--
Grant Edwards grante Yow! I'm an East Side
at TYPE...
visi.com

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

[Grant Edwards]

On 2006-07-16, ne*****@xit.net <ne*****@xit.netwrote:

>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.

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. ;)

--
Grant Edwards grante Yow! My mind is a potato
at field...
visi.com

[nephish]

cool enough, thanks !

-sk
Grant Edwards wrote:

On 2006-07-16, ne*****@xit.net <ne*****@xit.netwrote:

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.

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. ;)

--
Grant Edwards grante Yow! My mind is a potato
at field...
visi.com

[Cameron Laird]

In article <12*************@corp.supernews.com>,
Grant Edwards <gr****@visi.comwrote:

>On 2006-07-16, ne*****@xit.net <ne*****@xit.netwrote:

>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.

[Grant Edwards]

On 2006-07-17, Cameron Laird <cl****@lairds.uswrote:

>>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.

.
.
.
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.

--
Grant Edwards grante Yow! Xerox your lunch
at and file it under "sex
visi.com offenders"!

[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
Grant Edwards wrote:

On 2006-07-17, Cameron Laird <cl****@lairds.uswrote:

>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.

.
.
.
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.

--
Grant Edwards grante Yow! Xerox your lunch
at and file it under "sex
visi.com offenders"!

[Grant Edwards]

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

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.

--
Grant Edwards grante Yow! I'm CONTROLLED by
at the CIA!! EVERYONE is
visi.com controlled by the CIA!!

[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
Grant Edwards wrote:

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

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.

--
Grant Edwards grante Yow! I'm CONTROLLED by
at the CIA!! EVERYONE is
visi.com controlled by the CIA!!

[Grant Edwards]

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

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 "".

--
Grant Edwards grante Yow! Now I am depressed...
at
visi.com

[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 Edwards wrote:

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

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 "".

--
Grant Edwards grante Yow! Now I am depressed...
at
visi.com

[Grant Edwards]

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

>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,Tr ue)

--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.com it!

[nephish]

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

On 2006-07-17, ne*****@xit.net <ne*****@xit.netwrote:

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,Tr ue)

--
Grant Edwards grante Yow! Wow! Look!! A stray
at meatball!! Let's interview
visi.com it!

[Laszlo Nagy]

ne*****@xit.net í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

[John J. Lee]

Grant Edwards <gr****@visi.comwrites:
[...]

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.

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 <amtbytes "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

[bryanjugglercryptographer]

Grant Edwards wrote:

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.
--
--Bryan

[Lawrence D'Oliveiro]

In message <12*************@corp.supernews.com>, Grant Edwards wrote:

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?

[Steve Holden]

Lawrence D'Oliveiro wrote:

In message <12*************@corp.supernews.com>, Grant Edwards wrote:

>>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?

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
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden