Darren Reed writes: > You need to make this problem statement more detailed as it is > possible to use bind() to select a source address for UDP packets > but not in the scenario you're referring to here.
Indeed. The problem is that the user must either bind a zillion sockets (one for each local address on the system), using SIOCGIFCONF and then either polling or using routing sockets to keep track of interfaces that get reconfigured, or must bind/unbind for each packet he wants to send. Both are quite ugly, and application writers often get them wrong. > So in use, what I might find myself doing is: > > recvfrom(....) > getsockopt(..., IPPROTO_IP, IP_PKTINFO, .&info, &len) > build up a reply packet > setsockopt(..., IPPROTO_IP, IP_PKTINFO, &info, sizeof(info)) > sendto(...) > > - correct ? No. That won't work at all. The code above is reading and writing only the sticky options, which have nothing to do with received packets. Even if we could somehow make that work (we can't, and it's not how getsockopt has _ever_ functioned for _any_ option), it would not be thread-safe. You must use ancillary data for this feature. The fact that it ends up "working" with sticky data as well is a minor feature, and not a very important one. > Although UDP is given as being the source of the problem here, an IP > socket option is being presented. Will this work with stream protocols > such as TCP or only packet-orientated ones such as UDP/ICMP? It's sort of pointless for sockets that already have sensible listen-socket semantics. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
