Socket listening

 
Ian, and folks,

I'm trying to write a more robust Etoys server for OLPC, and found  
some surprising listening behavior.

The snippet below tries to listen on the same port twice. I'd have  
expected to get an error on the second listening attempt. However, on  
both Linux and Mac OS X (John's VM) I get back

        #(6060 57855)

which means the second socket listens successfully, but on a random  
port. I verified it is actually listening there using lsof. The  
SO_REUSEADDR option does not make any difference, btw.

So, is this intended behavior? If not, will we change it?

In my actual use case I would have tried to iterate through some ports  
to find an unbound one, so in this particular case the behavior is  
convenient for me. But I think I should not rely on it. Also, the same  
code gives an error (as expected) on Windows.

- Bert -

[
         p := 6060.

         s1 := Socket newTCP.
         s1 setOption: 'SO_REUSEADDR' value: 0.
         s1 listenOn: p.

         s2 := Socket newTCP.
         s2 setOption: 'SO_REUSEADDR' value: 0.
         s2 listenOn: p.

         {
                s1 isValid ifTrue: [s1 port].
          s2 isValid ifTrue: [s2 port]
        }
] ensure: [
         s1 destroy.
         s2 destroy.
]

 
Hi Bert,

On Jul 1, 2008, at 6:35 AM, Bert Freudenberg wrote:

> which means the second socket listens successfully, but on a random  
> port. I verified it is actually listening there using lsof. The  
> SO_REUSEADDR option does not make any difference, btw.
>
> I think I should not rely on it. Also, the same code gives an error  
> (as expected) on Windows.

The behaviour you're seeing seems broken to me; bind() should fail if  
another socket is already bound to the same listening address.  I'll  
take a look.

Cheers,
Ian

 

Am 01.07.2008 um 17:03 schrieb Ian Piumarta:


In the mean time I found that the new SocketAddressInfo-based code  
actually gives an error when binding, as expected. Only the old  
primitiveSocketListenWithOrWithoutBacklog silently binds to a random  
port.

- Bert -