[boost] Re: Sockets - what's the latest?

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
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...

Dick.Bridges_at_[hidden] 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
>                       <jhouse_at_[hidden]>         To:      boost_at_[hidden]
>                       Sent by:                   cc:
>                       boost-bounces_at_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