From: Jason House (jhouse_at_[hidden])
Date: 2003-02-13 15:08:44
Hey, that's a cool find.
I also found a homepage for SCTP http://www.sctp.de/
I've CC'd the point of contact from the website.
>From what I've read (which is fairly minimal :[), it looks like SCTP
would work well for what I was thinking.
I guess that my original commentary could be revised to some new
* How easy will support for SCTP be to work into the boost socket
library? ... and how easy would the interface be to use?
* I believe that the socket library is being written to allow different
protocols, but I wonder if it would handle multi-streamed protocols
easily. I don't know if this kind of implementation would most easily
be implemented as sockets inside of a socket...
> I'm just a lurker and maybe I missed something, but what you describe
> sounds like SCTP (RFC 2960 - the 'other' stream protocol). If the generic
> socket library supported SCTP, would that meet your requirements?
> Jason House
> <jhouse_at_[hidden]> To: boost_at_[hidden]
> Sent by: cc:
> boost-bounces_at_list Subject: [boost] Re: Sockets - what's the latest?
> 02/12/2003 03:11
> Please respond to
> Boost mailing list
> Once I heard there was a generic socket library in development, I thought
> I'd add
> a quick feature request. I would like to see the ability to have multiple
> streams through the same socket.
> Having had recent issues with a game and a proxy/firewall, I thought that I
> try and see if I can do a long shot that might have beneficial results for
> future... The problem with games, is that they try to form multiple
> between client and host.
> This boils down to providing two distinct benefits.
> 1: Programs can easily perform complex communications over a single port.
> 2: Without multiple streams, problems can occur when there are multiple
> behind a proxy connecting to a host outside of the proxy. If the client
> forms a single connection to the host, there won't be a problem because the
> source port will differentiate each stream. So, when multiple clients
> connect to
> a host from behind a proxy, the host can only differentiate each stream by
> random source port. So, when the clients form a second connection to the
> each stream gets differentiated from each other, but there is no mapping of
> source port ot the distinct client.
> Example of #2.
> Computers A & B connect to host H through proxy P. The host will see the
> following connections:
> P:1 => H:1
> P:2 => H:1
> P:3 => H:2
> P:4 => H:2
> There is no way to pair connections on H:2 with connections on H:1
> Now, without a proxy, it would be
> A:1 => H:1
> B:2 => H:1
> B:3 => H:2
> A:4 => H:2
> Now, it is very clear how to pair the connections... both connections from
> A go
> together, and both connections from B go together.
> Of course, this might not be a role specifically for a new stream type, It
> just be a wrapper of some kind. From the library standpoint, the wrapper
> kind of
> adds a distinctive type of functionality... I would like to somehow make
> it easy
> and intuitive for somebody considering multiple connections between two
> to use this different socket form instead. If it remains as an obscure
> combination of libraries, or as something unimplemented, it is likely that
> programs requiring multiple connections per client process to hit issues
> proxy servers.
> I'm interested to see what kind of reaction this creates from the list :)
> Is it normal to add a default wrapper to a library in order to make a
> common form
> of usage easier? I guess that the class responsible for handing how
> streams gets multiplexed could be made into some kind of template
> "Michel André" wrote:
> > > Anyone who was working on it - what's the current state of play? The
> > > flurry of mail on here a while back seemed to fizzle out. Is that
> > > because development has stalled?
> > > If I can help out with what limited time and knowledge of the subject
> > > I have I will. I really want to see this library in boost, and I know
> > > there are
> > > many others who do.
> > >
> > Hugo Duncan and I have been juggling ideas about a socket library for
> > and discussing on the boost wiki and partly on the list.
> > And we have started with an rough sketch of how a socket library for
> > could look like. It's currently checked in into the boost sandbox.
> > contains some of the discussions and details.
> > The work has not been progressing as much as I want due to a heavy
> > on my daytime job. But we certainly like some feedback on the progress so
> > far. Have we choosen a dead end or a viable path. The implementation in
> > sandbox has been compiled with gcc/cygwin, bcc and vc6.0 and vc7.0. So
> > need some input on porting to Unix especially the asynchrounous parts.
> > So I would say that we have a long road to travel to finnish
> > produce documentation test cases and all that. And when we have come that
> > far there is the formal review and i guess there will be a lot of heat
> > that will come ;).
> > So I wouldn't count on sockets to be a part of boost for some time
> > of course someone else submits another proposal or helps me and Hugo out
> > what we have so far to speed the progess).
> > Regards
> > /Michel
> > _______________________________________________
> > Unsubscribe & other changes:
> Unsubscribe & other changes:
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk