[issue2132] Blocking sockets take entirely too long to timeout

Sean Reifschneider report at bugs.python.org
Wed Mar 19 23:40:34 CET 2008


Sean Reifschneider <jafo at tummy.com> added the comment:

smtplib is for sending messages via SMTP, not for testing to see if a
user is behind an ISP that is incorrectly blocking outgoing SMTP
connections.  I would argue the "incorrectly" because they are dropping
rather than rejecting the connection packets.

One mechanism would be to use an alarm(30) call which would limit the
whole transaction to 30 seconds (connection, EHLO, RCPT, QUIT), not just
the connection.  My experience with dealing with remote machines in a
time-sensitive manner is that this approach is much more usable than
using socket timeouts.

A better mechanism is probably to use non-blocking socket I/O directly
and make connections to all or many of the remote servers and test them
in parallel, meaning all servers could be tested in 30 seconds (or
whatever your timeout is) rather than 5 minutes (you imply in your
message that you may be doing more than a dozen requests).

So, I believe the current functionality in the smtplib of being simple
and conservative at trying to get messages through, rather than trying
to be optimized for checking for account existance, is reasonable.  And
that in any case, using alarm() is a better solution than socket timeouts.

----------
nosy: +jafo
priority:  -> normal
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2132>
__________________________________


More information about the Python-bugs-list mailing list