Sebastien Roy writes: > > On Thu, 2009-05-14 at 14:40 -0400, James Carlson wrote: > > > This is the cleanest and most sensible approach, IMO. A new ancillary > > > data type that specifies the source address and/or port makes sense to > > > me. > > > > Yep. You could call it IP_PKTINFO. ;-} > > That only goes part of the way, though. If I understood the problem > correctly, the application also needs to specify the source port, and > presumably the transport layer would need to drop the packet if that > port was in use. > > I may be misinterpreting the intent of the function, but as Dan > specified it, it takes a full source sockaddr, and not just an IP source > address.
Good point. I'd actually expect that setting the source port on a packet-by-packet basis is not required, and the source port could be supplied by just binding the socket first with INADDR_ANY and the desired port. In fact, I think setting the source port via ancillary data would itself be a Very Bad Thing, because (unlike setting the address) there's no way it could be done safely. The addresses can be checked against the interfaces to make sure you're not forging something, but how do you check that the port being used is one you "should" use? -- James Carlson, Solaris Networking <[email protected]> Sun Microsystems / 35 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]
