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 questions: * 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... [EMAIL PROTECTED] wrote: > > 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 > <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] > Sent by: cc: > boost-bounces@list Subject: [boost] Re: Sockets - >what's the latest? > s.boost.org > > > 02/12/2003 03:11 > PM > 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 > might > try and see if I can do a long shot that might have beneficial results for > the > future... The problem with games, is that they try to form multiple > connections > 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 > clients > behind a proxy connecting to a host outside of the proxy. If the client > only > forms a single connection to the host, there won't be a problem because the > random > 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 > the > random source port. So, when the clients form a second connection to the > host, > each stream gets differentiated from each other, but there is no mapping of > random > 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 > could > 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 > computers > 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 > with > 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 > multiple > streams gets multiplexed could be made into some kind of template > parameter... > > "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 > boost > > 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 > boost > > could look like. It's currently checked in into the boost sandbox. > > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket > > contains some of the discussions and details. > > > > The work has not been progressing as much as I want due to a heavy > workload > > 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 > the > > sandbox has been compiled with gcc/cygwin, bcc and vc6.0 and vc7.0. So > we > > 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 > implementation, > > 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 > when > > that will come ;). > > > > So I wouldn't count on sockets to be a part of boost for some time > (unless > > of course someone else submits another proposal or helps me and Hugo out > on > > what we have so far to speed the progess). > > > > Regards > > /Michel > > > > _______________________________________________ > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
