This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients diekmann, neologix, pitrou
Date 2010-12-08.18:51:55
SpamBayes Score 0.00094783754
Marked as misclassified No
Message-id <1291834316.56.0.821127842863.issue10644@psf.upfronthosting.co.za>
In-reply-to
Content
>  it may be very convenient and the performance overhead may be barely noticeable.

Convenient for what ?
If the remote end doesn't send a FIN or RST packet, then the TCP/IP stack has no way of knowing the remote end is down.
Successfull return of send(2) never meant a succesfull delivery to the other end, see man page :
"No indication of failure to deliver is implicit in a send(). Locally detected errors are indicated by a return value of -1. "

If your remote application doesn't close its socket cleanly, then your application is broken.
To guard against that, you could use TCP keepalive...
History
Date User Action Args
2010-12-08 18:51:56neologixsetrecipients: + neologix, pitrou, diekmann
2010-12-08 18:51:56neologixsetmessageid: <1291834316.56.0.821127842863.issue10644@psf.upfronthosting.co.za>
2010-12-08 18:51:55neologixlinkissue10644 messages
2010-12-08 18:51:55neologixcreate