Date: Mon, 04 Mar 2002 09:05:56 -0800
From: Terry Lambert <tlambert2@mindspring.com>
To: arch@freebsd.org
Subject: Re: proposition for new socket syscalls {send,recv}fromto
Message-ID: <3C83A974.96E2895C@mindspring.com>
next in thread | raw e-mail | index | archive | help
> > I agree that these calls are necessary and should have been presend from > > the start, but you seem to be unaware of the usual way of implementing > > UDP servers that are aware of multihoming, such as BIND. They typically > > use SIOCGIFADDR to read the list of interfaces on the machine then bind > > a socket to each one. The server can choose the appropriate socket to > > use according to the source address that is required. However this > > doesn't deal all that well with a dynamically changing list of interface > > addresses... > > Hm, from looking at the BIND code it seems to reload the list of interfaces > periodically, so it can handle the changing list of interfaces. And it has > a fair amount of code dealing with it. But not all the servers do this: > for instance, tftpd does not. On the receive side, the problem isn't interfaces so much as it is IP addresses. Specifically, the problem is that it's binding to the IP addresses in the first place, rather than binding to the interfaces, regardless of which IP addresses are or are not on them. From the original posting about the failover scenario with IP takeover, the takeover issue would be resolved, in the receive case by simply binding to the interface rather than addresses. IP addresses could then come and go, and the daemon would get the packets when the IP was there, and not when the IP wasn't. I've often wanted this capability on dialup gateway machines, where the daemons would not require restart, if the bind were this way, and the local host name was not cached data from an interface probe (e.g. sendmail's idea of the name to give in the EHLO on outbound or the name to give in the greeting on inbound). On the send case, the main issue is, I think, responses. In fact, I can't easily come up with a non-hacking case where there is not a packet on a know interface that is eliciting a reply on an unknown interface that is not handled by response only. This implies that a receive of the packet with source information -- something which is already handled in the context of the existing API -- is enough, if there is a "sendfrom" which took the receive context for the reply; I would want the sendfrom, however, to verify that the address it was sending from was in fact local. Another issue that occurst to me, but is only slightly related to the API issue, if at all, is that it should be possible to add an option to the "ifconfig" of an address or alias, such that the local machine did not ARP for the IP address. Specifically, for DSR (Direct SErver Return), this is a requirement to avoid confusing Cisco, Extreme Networks, and other switches. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C83A974.96E2895C>