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:
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.
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 -
vm-dev@lists.squeakfoundation.org