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
