Boost logo

Boost :

From: Dick.Bridges_at_[hidden]
Date: 2003-02-13 10:48:57

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:

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