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

[Alexander Larsson <alexl redhat com>]

On Sun, 2009-05-10 at 10:53 -0400, Dan Winship wrote:
> 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?

I dunno. If the socket has SO_REUSEADDR, and some port is in TCP WAIT
state on that port, isn't it considered not in use and may be picked?
This is my main worry with having SO_REUSEADDR automatically set on
client sockets.

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

Yeah, i wrote listen above, but i meant connect. Like if you have two
network interfaces and want to be sure you're connecting on one of them
in particular, then you'd bind to the ip of that interface, but with
port 0.

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

I don't know how rcmd/etc work, do they require a specific source port
for the connection?