Just another lurker view: maybe boost can lead by following not too far out in front.
The linux people seem to be well on their way to providing SCTP support at the kernel level. The home page for the project is at http://lksctp.sourceforge.net/. Searching MSFT online and privatenews yielded nothing. I posted a query on privatenews but don't really expect an answer - MSFT policy and all. In any case, the linux site references an ietf draft (http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-05.txt) that "...describes a mapping of the Stream Control Transmission Protocol SCTP RFC2960 [8] into a sockets API." Maybe it would be sufficient to design the boost socket library in anticipation. (IMHO VoIP is going to push everyone to support SCTP in short order.) FWIW: I think "policy_based_smart_socket" has a nice ring to it. ;) Jason House <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent by: cc: [EMAIL PROTECTED] boost-bounces@list Subject: [boost] Re: Sockets - what's the latest? s.boost.org 02/14/2003 06:26 AM Please respond to Boost mailing list Well, I agree that any exprerimental/not widely used protocol should be able to run over another more common protocol... for a number of reasons... One would be privilages... another would be recognition by firewalls, etc... I don't think that it would be tough to make code use either a raw or a UDP socket... Brian Gray wrote: > > On Thursday, February 13, 2003, at 12:08 PM, Jason House wrote: > > * How easy will support for SCTP be to work into the boost socket > > library? ... and how easy would the interface be to use? > > I looked at the docs on www.sctp.de and downloaded the source, and the > fatal flaw seems to be what I found in adaptation.c. It appears both > the routing socket and the sctp socket are built on raw IP. At least > on Linux, Darwin, and Windows NT/2000, you need root privileges to open > one of these. Thus, the daemon to handle the protocol will have to be > installed by and run as an administrator, and will therefore not be > usable by many clients who do not control the machine they use. > > I think a UDP-based implementation rather than a raw IP-based one would > do as well (with some wasted overhead) and not need admin privileges or > the cooperation of the operating system manufacturer to get installed. > Does anyone know if there is a UDP-based implementation? > > -- Brian > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
