Re: socket.unbind or socket.unlisten? - socket.error: (48, 'Addressalready in use')
Hendrik van Rooyen
> I have a program that uses socket.bind() and socket.listen() frequently.
> After that program stops, it is not able to bind() again for a while:
>
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
This does the trick for me.
- Hendrik
Jean-Paul Calderone
>I have a program that uses socket.bind() and socket.listen() frequently.
>After that program stops, it is not able to bind() again for a while:
>
>__init__
> self.serversocket.bind((self.listen_address,self.port))
> File "<string>", line 1, in bind
>socket.error: (48, 'Address already in use')
>
>
>The problem with this, is that this server program SOMETIMES need to be
>restarted very quickly. I tried to find the solution in the socket module.
>But there is no "socket.unbind" or "socket.unlisten". How can I tell the OS
>that I do not want to listen on that address anymore, so other programs can
>bind on it immediatelly?
>
>(Yes I know that I can use setsockopt to allow listening multiple sockets on
>the same address, but this is NOT what I need...)
Actually, SO_REUSEADDR is probably just what you want. Since I can't see
your code and I don't know under what situations it fails, I can only guess
at the problem, but my guess is that you have connections from the first run
of your app left in the TIME_WAIT state and they are preventing you from
binding to the address again in the second run of your app. Setting the
SO_REUSEADDR flag on POSIX fixes this problem (don't set it on Windows,
though).
Jean-Paul
Hendrik van Rooyen
8<------------------------------
> ....... Setting the
> SO_REUSEADDR flag on POSIX fixes this problem (don't set it on Windows,
> though).
Why not? I have been merrily setting it, and I have not noticed anything weird.
(yet)
- Hendrik
Laszlo Nagy
> 8<------------------------------
>
>
>> ....... Setting the
>> SO_REUSEADDR flag on POSIX fixes this problem (don't set it on Windows,
>> though).
>>
>
> Why not? I have been merrily setting it, and I have not noticed anything weird.
> (yet)
>
use setsockopt and be able to listen on the same port from many
processes. I knew that I could use SO_REUSEADDR, but I'm heistating to
do so. I must guarantee that only one process listens on a given port at
the same time.
Maybe I could use some kind of locking, but it would be too difficult:
- mutexes are great but they are platform dependent and they are not in
the standard lib
- the listening processes do not see each other's home directory so file
locking cannot be used for this
- these processes will probably listen on many ports at the same time,
it is also a problem with mutexes/file locks (who wants 50 lock files to
be created?)
Best,
Laszlo
Steve Holden
>
>> 8<------------------------------
>>
>>
>>> ....... Setting the
>>> SO_REUSEADDR flag on POSIX fixes this problem (don't set it on Windows,
>>> though).
>>>
>>
>> Why not? I have been merrily setting it, and I have not noticed
>> anything weird.
>> (yet)
>>
> Please see my original post. I specifically stated that I do not want to
> use setsockopt and be able to listen on the same port from many
> processes. I knew that I could use SO_REUSEADDR, but I'm heistating to
> do so. I must guarantee that only one process listens on a given port at
> the same time.
>
SO_REUSEADDR flag.
SO_REUSEADDR should be used to avoid the TIME_WAIT state when the
current listening process terminates. If you do not use it then there
will be a certain period during which no other process can listen on
that port, and it will be reusable only after the TIME_WAIT is over.
This can easily be seen by using the netstat utility.
See "Pitfall 3" in
http://www.ibm.com/developerworks/linux/library/l-sockpit/index.html
> Maybe I could use some kind of locking, but it would be too difficult:
>
> - mutexes are great but they are platform dependent and they are not in
> the standard lib
> - the listening processes do not see each other's home directory so file
> locking cannot be used for this
> - these processes will probably listen on many ports at the same time,
> it is also a problem with mutexes/file locks (who wants 50 lock files to
> be created?)
>
Complete red herring: there is no way for multiple processes to listen
to the same port: this would lead to ambiguity in the protocol stack.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Steve Holden
>
>> 8<------------------------------
>>
>>
>>> ....... Setting the
>>> SO_REUSEADDR flag on POSIX fixes this problem (don't set it on Windows,
>>> though).
>>>
>>
>> Why not? I have been merrily setting it, and I have not noticed
>> anything weird.
>> (yet)
>>
> Please see my original post. I specifically stated that I do not want to
> use setsockopt and be able to listen on the same port from many
> processes. I knew that I could use SO_REUSEADDR, but I'm heistating to
> do so. I must guarantee that only one process listens on a given port at
> the same time.
My previous reply assumed you are running some UNIX-like operating
system. If you are on Windows then Jean-Paul's advice stands, as Windows
*does* allow several processes to listen on the same port and randomly
delivers incoming connections to one of the listening processes.
I believe this is because Microsoft failed to understand the original
meaning of SO_REUSEADDR for their early TCP implementations, and
persisted with this ghastly error in the name of backwards
compatibility, justifying it by suggesting that listener pools could be
created. Or some such nonsense. Perhaps someone with more insight into
the development process could comment. It seems to me it's completely
bizarre.
However, under Windows 2000 and later you should find there's an
SO_EXCLUSIVEADDRUSE flag which you can use to ensure a single listener -
see http://msdn.microsoft.com/en-us/library/ms740621(VS.85).aspx. No
need for separate locks.
Grant Edwards
> I believe this is because Microsoft failed to understand the
> original meaning of ___________________, and persisted with
> this ghastly error in the name of backwards compatibility,
> justifying it by suggesting that _________________________.
Somebody should have cards printed up...
--
Grant
Hendrik van Rooyen
"Steve Holden" <st.@hol.eb.com> wrote:
>
> My previous reply assumed you are running some UNIX-like operating
> system. If you are on Windows then Jean-Paul's advice stands, as Windows
> *does* allow several processes to listen on the same port and randomly
> delivers incoming connections to one of the listening processes.
>
> I believe this is because Microsoft failed to understand the original
> meaning of SO_REUSEADDR for their early TCP implementations, and
> persisted with this ghastly error in the name of backwards
> compatibility, justifying it by suggesting that listener pools could be
> created. Or some such nonsense. Perhaps someone with more insight into
> the development process could comment. It seems to me it's completely
> bizarre.
>
> However, under Windows 2000 and later you should find there's an
> SO_EXCLUSIVEADDRUSE flag which you can use to ensure a single listener -
> see http://msdn.microsoft.com/en-us/library/ms740621(VS.85).aspx. No
> need for separate locks.
>
Thanks Steve - I am not the OP, I was just curious as to why
Jean-Paul was saying what he did - so the only reason I have
not been bitten on windoze yet must be either because I am
lucky, or because my server side stuff is linux and there is the
occasional windows client. So I don't really listen on windows.
"a pool of listeners" - just think of the fun one can have trying to
keep state between them - would be a marvellous job if someone
else is paying top dollar by the hour - I can just see the team growing
as the need for new specialists are discovered as one goes along.
:-)
- Hendrik
Aahz
+1 QOTW
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
Weinberg's Second Law: If builders built buildings the way programmers wrote
programs, then the first woodpecker that came along would destroy civilization.