Julian Elischer wrote:
Craig Rodrigues wrote:
On Fri, Dec 15, 2006 at 05:57:04AM -0800, Luigi Rizzo wrote:
i think Andre's question was this:
normally we use {set|get}sockopt() to configure the socket
as desired for special features (e.g. multicast is one).
Why is it undesirable to use the same kind of overloading
for sctp ?
I think some of the reasons for why a new sockets API
was introduced for SCTP was outlined in:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-14.txt
which says:
--------------
8. New Interfaces
Depending on the system, the following interface can be implemented
as a system call or library function.
---------------
The latter is what I'd expect..
syscalls is 'unusual' and unique to this protocol.
...but I'll let Randall chime in too. :)
There are only 4 new system calls..
a) sctp_generic_sendmsg()
b) sctp_generic_sendmsg_iov()
c) sctp_generic_recvmsg()
d) sctp_peeloff()
Peeloff is a lot like accept() .. it returns a new
socket. It could be move to a socket option petty
easily.. Michael Tuexen already did one for Apple :-)
a/b are the same in reality its just one accepts an
IOV which I anticipate will get added to the socket api
eventually.
In general a/b/c are there for efficency.. an app hits
these heavily.. and going through socket options OR
packing and unpacking CMSG structures (both in the
user land library and in the kernel) is a HUGE cpu
waste...
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
