Boost logo

Boost :

From: Dick.Bridges_at_[hidden]
Date: 2003-02-14 11:44:50

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 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
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
                      <jhouse_at_[hidden]> To: boost_at_[hidden]
                      Sent by: cc: sctp_at_[hidden]
                      boost-bounces_at_list Subject: [boost] Re: Sockets - what's the latest?
                      02/14/2003 06:26
                      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 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:

Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at