Kacheong Poon writes: > Just wondering, does it make sense to have a "send" function > which takes both source and destination addresses as arguments > instead of using ancillary data?
Exploding the list of send*() variants didn't make sense to me when we have something easily extensible like ancillary data, and when effective extension of the function call interface would likely include running the standards gauntlet. (E.g., 3XNET would give you ancillary data, but not "pollution" from any non-standard interfaces, and 3SOCKET would give you the new feature but not ancillary data.) Plus, it's already implemented as ancillary data on IPv6, so it seems odd to do it so very much differently for IPv4. > To be symmetric, does it > make sense to have a "receive" function to return both source > and destination addresses? I guess an app can have two wrapper > functions which make use of ancillary data to do that. But > if we think that they are useful, we may as well provide them. We already have receive functions that provide source address. I suppose we could invent convenience wrappers for ancillary data, but I'm not sure that's a necessary part of the project. -- 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]
