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

From: Jason House (jhouse_at_[hidden])
Date: 2003-02-12 18:11:59

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