By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,306 Members | 1,621 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,306 IT Pros & Developers. It's quick & easy.

Why does SocketServer default allow_reuse_address = false?

P: n/a
Considering that UNIX Network Programming, Vol 1 (by W. Richard Stevens)
recommends "_All_ TCP servers should specify [SO_REUSEADDR] to allow the
server to be restarted [if there are clients connected]," and that
self.allow_reuse_address = False makes restarting a server a pain if there
were connected clients, why does SocketServer default allow_reuse_address
to False? It's kind of bemusing to subclass ThreadingTCPServer just to
change one variable that arguably should have been True in the first place.

Is there some history to this of which I'm not aware? Is there a good
reason for it to default to false?

j

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ *ID 0xDB26D7CE

--
Posted via a free Usenet account from http://www.teranews.com

Feb 27 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Joshua J. Kugler wrote:
Considering that UNIX Network Programming, Vol 1 (by W. Richard Stevens)
recommends "_All_ TCP servers should specify [SO_REUSEADDR] to allow the
server to be restarted [if there are clients connected]," and that
self.allow_reuse_address = False makes restarting a server a pain if there
were connected clients, why does SocketServer default allow_reuse_address
to False? It's kind of bemusing to subclass ThreadingTCPServer just to
change one variable that arguably should have been True in the first place.

Is there some history to this of which I'm not aware? Is there a good
reason for it to default to false?
If any, don't know. Searched in already reported bugs to check if
somebody already noticed.

If not, please consider to open a bug.

Regards,

--
.. Facundo
..
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

Mar 5 '07 #2

P: n/a
On Feb 26, 5:54 pm, "Joshua J. Kugler" <jos...@eeinternet.comwrote:
Considering that UNIX Network Programming, Vol 1 (by W. Richard Stevens)
recommends "_All_ TCP servers should specify [SO_REUSEADDR] to allow the
server to be restarted [if there are clients connected]," and that
self.allow_reuse_address = False makes restarting a server a pain if there
were connected clients, why does SocketServer default allow_reuse_address
to False? It's kind of bemusing to subclass ThreadingTCPServer just to
change one variable that arguably should have been True in the first place.

Is there some history to this of which I'm not aware? Is there a good
reason for it to default to false?
Yes, it is there for a good reason. Security is the primary focus of
that option. If you enable that option, rogue applications can assume
service processing under a number of server failure conditions. In
other words, start your rogue, crash the primary service, and you now
have a rogue service running. Even periodic checks will show the
server is still running. Under a number of other configurations, it
is also possible for the rogue service to simply start and usurp some
types of IP traffic on certain OSs which would otherwise be delivered
to your real server.

Contrary to the book, blindly enabling SO_REUSEADDR is a very, very
bad idea unless you completely understand the problem domain. I'm
sure Stevens' does understand so it makes for a good choice for him.
On the other hand, most people don't understand the implications so it
makes for a very, very poor move from a security perspective.

Long story short, it is not a bug. It is a feature. The proper
default is that of the OS, which is to ensure SO_REUSEADDR is disabled
unless you absoluetely understand what you're buying by enabling it.
Greg

Mar 7 '07 #3

P: n/a
Greg Copeland wrote:
>Is there some history to this of which I'm not aware? Is there a good
reason for it to default to false?
<SNIP Greg's very informative reply>
Long story short, it is not a bug. It is a feature. The proper
default is that of the OS, which is to ensure SO_REUSEADDR is disabled
unless you absoluetely understand what you're buying by enabling it.
Thanks for your reply. Those are all point of which I had not been aware.

My problem (and the reason I set reuse to True) is this: if I have
connections active when I restart my service, upon restart, the socket will
fail to bind because there is still a connection in a WAIT state. And
until that old connection goes away (30 seconds or so?) I cannot restart
the service. So, the only option would be to sit there in a loop calling
serve_forever until it doesn't throw a "can't bind to socket" exception.

Or is there something I'm *really* missing about the way SocketServer is
supposed to work? Am I supposed to notify my connection threads to shut
down and disconnect "properly?" Which gets even more fun since they are
sitting there waiting for input on the connection and not in a position to
respond to other events...gets back to the fun of "killing" threads that
are blocking.

j

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ *ID 0xDB26D7CE

--
Posted via a free Usenet account from http://www.teranews.com

Mar 7 '07 #4

P: n/a
On 3/7/07, Joshua J. Kugler <jo****@eeinternet.comwrote:
Greg Copeland wrote:
Is there some history to this of which I'm not aware? Is there a good
reason for it to default to false?
<SNIP Greg's very informative reply>
Long story short, it is not a bug. It is a feature. The proper
default is that of the OS, which is to ensure SO_REUSEADDR is disabled
unless you absoluetely understand what you're buying by enabling it.

Thanks for your reply. Those are all point of which I had not been aware.

My problem (and the reason I set reuse to True) is this: if I have
connections active when I restart my service, upon restart, the socket will
fail to bind because there is still a connection in a WAIT state. And
until that old connection goes away (30 seconds or so?) I cannot restart
the service. So, the only option would be to sit there in a loop calling
serve_forever until it doesn't throw a "can't bind to socket" exception.

Or is there something I'm *really* missing about the way SocketServer is
supposed to work? Am I supposed to notify my connection threads to shut
down and disconnect "properly?" Which gets even more fun since they are
sitting there waiting for input on the connection and not in a position to
respond to other events...gets back to the fun of "killing" threads that
are blocking.

j
This is just the way sockets work on your platform. How exactly
sockets shut down, and the exact effect that SO_REUSEADDR varies from
platform to platform. In your case, using it is probably reasonable.
Mar 7 '07 #5

P: n/a
Chris Mellon wrote:
>My problem (and the reason I set reuse to True) is this: if I have
connections active when I restart my service, upon restart, the socket
will
fail to bind because there is still a connection in a WAIT state.

This is just the way sockets work on your platform. How exactly
sockets shut down, and the exact effect that SO_REUSEADDR varies from
platform to platform. In your case, using it is probably reasonable.
Thank you. Glad to know I've chosen the best solution for my situation.

j

--
Joshua Kugler
Lead System Admin -- Senior Programmer
http://www.eeinternet.com
PGP Key: http://pgp.mit.edu/ *ID 0xDB26D7CE

--
Posted via a free Usenet account from http://www.teranews.com

Mar 7 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.