I have been able to reproduce the same results with a simple C++ example. I have been unable to find any specific reason why binding to "127.0.0.1" and later calling getsockname would result in a different address of "0.0.0.0" I did find one reference [1] that said that using a port number of 0 will cause the operating system to listen on all interfaces and that calling getsockname may not return a valid address until the socket is fully connected. It might be best to use the original patch that I sumbitted that only uses the port value from the getsockname call, and uses the correct "127.0.0.1" IP address regardless of the reported address. If the address returned is really undefined, then this could be causing the problem. -Aron [1] http://www.sockets.com/winsock.htm#Bind [2] Change the following line in posixbase.py client.connect(server.getsockname()) to client.connect(('127.0.0.1', server.getsockname()[1])) On Mon, Apr 20, 2009 at 7:06 PM, Jean-Paul Calderone <exarkun@divmod.com> wrote:
On Mon, 20 Apr 2009 18:16:39 -0500, Aron Bierbaum <aronbierbaum@gmail.com> wrote:
I have looked into this a little more and have noticed that if I specify a port number instead of "0" it will always bind to the correct "127.0.0.1" address. I still don't know why this only occurs on certain Windows machines. I will hopefully get more time to look into this in the next couple of days.
Hmm. Interesting. Perhaps we could bind a different port, then. I look forward to results from your further investigations.
Jean-Paul
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python