On 2006-07-17, Cameron Laird <[EMAIL PROTECTED]> wrote:
>>> 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"!
--
http://mail.python.org/mailman/listinfo/python-list
