James Carlson wrote:
I'd be rather surprised if applications needing this sort of feature
are significantly affected by anything related to ancillary data
(compared both to the other work they typically do, and compared to
the overhead issues of having to deal with very large numbers of
peers),
Just an imaginary example, it is an app switch dealing
with a large number of different peers. But the
processing of an input packet can be minimal, it just
needs to find out where to forward the app message to
using which source address. So one major cost is
the kernel/user traversal. Using ancillary data can
contribute a not so small percentage in this.
but the definitive test would be to create an experimental
new interface for this and then measure to see if there is any
noticable overall improvement.
I just want to know if folks see this as a potential
useful call worthwhile to prototype. I don't know
what other real apps require it. Actually, one such
app may not talk to a large number of peers, just a
couple. Using the existing socket interface, I guess
the app creates multiple socket for this. This requires
the app to do socket management. So sendfromto() and
recvfromto() can be useful.
--
K. Poon.
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
