Re: windows [Re: Review of gnio, round 2]

[Dan Winship <danw gnome org>]

Alexander Larsson wrote:
>> I was going to say "we could make g_socket_listen() set it" but
>> actually, you need to do it before calling bind(). I'm not really
>> familiar with the use cases of bind() on client sockets, but it  seems
>> like probably if the application is trying to bind to a specific local
>> port, even for a client socket, then it probably really does want that
>> port, so setting SO_REUSEADDR in g_socket_bind() even in the client case
>> should be ok. Alternatively, maybe g_socket_bind() could just take a
>> flag saying whether or not to set SO_REUSEADDR, or else
>> g_socket_listen() could be modified to do both bind() and listen() (and
>> SO_REUSEADDR), and then g_socket_bind() would be only for the
>> client-side case and would not set SO_REUSEADDR. (This moves a little
>> further from the underlying API, but it's always seemed a little
>> pointless to me to have bind and listen be separate syscalls anyway...)
> 
> Bind in the client is mainly done when you want to listen to only one
> interface, so then generally port == 0, so i guess we could autoset this
> if port == 0 when binding to a IPV4 or IPV6 SOCKET_STREAM type with NULL
> or "tcp" protocol.

If port==0 then SO_REUSEADDR is irrelevant because the kernel is going
to assign you a port that's not in use anyway, right?

And anyway, I was talking about the case where you bind() and then
connect(), not bind() and then listen(). If you're listening, then from
an API POV, you're a server and presumably want SO_REUSEADDR (if you're
listening on a specific port), even if you're a client from the protocol
POV (eg, an ftp client doing an active transfer).

But if you bind() and then connect() (eg, like the rcmd/rsh/rlogin
suite) then maybe you don't want SO_REUSEADDR. (And looking at the glibc
source for rresvport(), it doesn't use SO_REUSEADDR, and instead just
keeps trying different ports at random until it either succeeds or gets
an error other than EADDRINUSE.) I'm not sure if there are use cases for
bind+connect that don't involve prehistoric "authentication" models...

-- Dan