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 16 bits.

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 app server.

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.

-Stuart -



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.

  Ian
    

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, 
no more".

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".