If you were using a port number of 80000, it was probably broken for
three years. The TCP port number is a 16 bit value which limits you to
64K. For reference, see section 3.1 of rfc 793
http://www.faqs.org/rfcs/rfc793.html Source and Destination ports are
The new code uses the sockaddr as returned by the sock.getsockname() to
determine which handler to use. The getsockname is returning a number
which has already been truncated into the 16 bit value.
The old code did no such thing, and only did a getsockname() comparison
for the monitor port (which would have failed if the monitor port was
> 64k). If it wasn't the monitor port then it assumed it to be the
My guess is that for this to have worked, nobody was doing a range
check on the port in the past, and it was just silently getting mapped
into the 16 bit value.
Chuck Esterbrook wrote:
On Sunday 30 March 2003 05:37 pm, Ian Bicking wrote:
On Sun, 2003-03-30 at 18:48, Chuck Esterbrook wrote:
On a hunch, I changed the port from its original value of 80000 to
9999 and now it works. I then reversed the situation: I installed
fresh copies of Apache and WebwareCVS, got them working, then
pumped up the port # to 70001 and got this:
KeyError: ('127.0.0.1', 4465)
Looks like a classic case of 16bit vs 32bit. I thought those days
were over! :)
That's just the way it is, there's 65k ports, no more. It should
never work, though confusingly it seems to be just cutting off the
high bits. I suppose there should be an assert somewhere to make sure
you don't try anything too large.
Port 80000 worked for almost 3 years and stopped working under the new
ThreadedAppServer.py just ten days ago. That belies "there's 65k ports,
I'm guessing that a library used by the new code is arbitrarily chopping
things off. It's not the end of the world, but it's unfortunate that
some libraries still "exist in a 16-bit world".