Laszlo Nagy wrote: > >> 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. > This appears to demonstrate a misunderstanding of the purpose of the 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/ -- http://mail.python.org/mailman/listinfo/python-list
