On Wed, 8 Jun 2011 10:39:08 -0700 greearb@xxxxxxxxxxxxxxx wrote: > From: Ben Greear <greearb@xxxxxxxxxxxxxxx> > > This lets one specify the source IP address for > sockets, allowing users to leverage routing rules > on multi-homed systems. > I gotta say I think this is rather horrible..... As I understand it, the problem is bindresvport. It binds to a port number before making a connection, so the local address that is bound to is the 'default' rather than the best one to reach the given target. And in some network configs this can be bad, because e.g. the target may not be able to reply to that 'default' address. So you want to be able to specify the local endpoint fully when you bind, so you require/allow the user to specify the local endpoint. Wouldn't it be soooo much nicer if the tools could just figure out the 'correct' local endpoint and just use that? Obviously "yes" but maybe that isn't straight forward. Have you looked into that at all? Worst case (which may be so incredibly bad it isn't worth considering) is that we could extract the routing table from the kernel and "figure it out". But I suspect there is an easier way... What if you create a UDP socket, 'connect' to some arbitrary port on the target machine, and then use getsockname to get the local endpoint address of that socket. That wouldn't generate any network traffic, but should give you the preferred local endpoint for talking to that peer?? For the in-kernel code I wouldn't accept a trick like that, but there is presumably some way to find the preferred local endpoint for some address more directly ... certainly worth asking on net-dev if we cannot figure one out. So I'm thinking: yes, there is a real need, but I think there must be a better solution. What think you? Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
