On Wed, Feb 12, 2003 at 06:11:59PM -0500, Jason House wrote:
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.
This boils down to providing two
On Mon, 3 Mar 2003 18:17:45 +0100, Wesley W. Terpstra [EMAIL PROTECTED]
darmstadt.de wrote:
How about BEEP ?
It's not only P2P protocol, but also refactoring of some protocols.
#beepcore.org
http://www.beepcore.org/
#XML Watch: Bird's-eye BEEP
Part 1 of an introduction to the Blocks
I don't know exactly what you mean by non-trivial sever and what you
get from ACE/expect not to get from Boost.Socket that a non-trivial
server requires?
Depends on the server, CDR formatting, thread-safe queues come to mind.
There are probably a few threading things as well. Of course all
-Original Message-
From: Jeff Garland [mailto:[EMAIL PROTECTED]]
I agree that multiplexing has to be in the design thoughts and
ultimately part of boost, but I worry it will be too much
to deliver, test, and review in the first pass. And,
I see no way I would use Boost.Socket for
Well, I agree that any exprerimental/not widely used protocol should be
able to run over another more common protocol... for a number of
reasons... One would be privilages... another would be recognition by
firewalls, etc... I don't think that it would be tough to make code use
either a raw or
[...]
How about borrowing ideas from ACE, but implementing them in
modern C++? Or has that been discussed already? Or is the ACE
framework too obsolete-C++ to be a useful design?
We probably should at least consider ACE ideas. But I guess this would
require several of us to dig
...various comments about ACE from various authors
[...]
How about borrowing ideas from ACE, but implementing them in
modern C++? Or has that been discussed already? Or is the ACE
framework too obsolete-C++ to be a useful design?
We probably should at least consider ACE ideas.
PROTECTED]
Sent by: cc: [EMAIL PROTECTED]
boost-bounces@list Subject: [boost] Re: Sockets - what's
the latest
On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
So in summary, I think we should focus the Boost.Socket effort
on what is currently described as 'level 1 - OS platform layer'
and 'level 2 - basic connectivity layer' leaving multiplexing
for later. I'm sure this will be
Brian Gray wrote:
At the very end of it, network programmers should be using a
callback-driven interface and not have to worry about multiplexing at
all, but I agree that for now a third layer should be deferred until
the basic groundwork has been laid out.
Sometimes it pays to design the
On Friday, February 14, 2003, at 09:12 AM, Peter Dimov wrote:
Brian Gray wrote:
At the very end of it, network programmers should be using a
callback-driven interface and not have to worry about multiplexing at
all, but I agree that for now a third layer should be deferred until
the basic
On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote:
So in summary, I think we should focus the Boost.Socket effort
on what is currently described as 'level 1 - OS platform layer'
and 'level 2 - basic connectivity layer' leaving multiplexing
for later. I'm sure this will be
supported SCTP, would that meet your requirements?
Jason House
[EMAIL PROTECTED] To: [EMAIL PROTECTED]
Sent by: cc:
boost-bounces@list Subject: [boost] Re: Sockets
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jason House
Sent: Thursday, February 13, 2003 9:09 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [boost] Re: Sockets - what's the latest?
I guess that my original commentary could
Boris Schäling [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
[...]
Noone knows as there is no consensus on how the library's
architecture should look like. There are different approaches and
proposals at Boost Wiki and in the sandbox but what's still missing
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of David B. Held
Sent: Thursday, February 13, 2003 10:57 PM
To: [EMAIL PROTECTED]
Subject: [boost] Re: Sockets - what's the latest?
[...]
How about borrowing ideas from ACE, but implementing them
Boris Schäling [EMAIL PROTECTED] writes:
[...]
How about borrowing ideas from ACE, but implementing them in
modern C++? Or has that been discussed already? Or is the ACE
framework too obsolete-C++ to be a useful design?
We probably should at least consider ACE ideas. But I guess this
On Wednesday, February 12, 2003, at 03:11 PM, Jason House wrote:
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.
This is pseudo-doable over TCP, by
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
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
If you are interested, please comment on it. I would especially like to
know if the benefits of an Acceptor/Connector pattern would outweigh the
additional complexity involved (specifically, how much more complicated
the sample test.cpp file would get). Thanks!
Basically the beginning would
Blue, Reginald V wrote:
The question I have is: Is it likely for any of them to make it into the
main CVS stream?
I'm quite the lurker too g
Sockets seems to be actively under development at the moment. Most of
the activity seems to be on the Wiki at the moment though:
Michel,
On Sun, 24 Nov 2002 13:24:38 +0100, Michel André [EMAIL PROTECTED] wrote:
How do i access the cvs sandbox?
cvs update -P (in directory C:\Packages\boost_sandbox\)
cvs server: Updating .
Sorry - I missed this message. Hopefully you have gained access by now,
but if not then you
Eric Woodruff wrote:
snip
* Support for Event-Driven and Blocking sockets This one should go
without saying. The event-driven support can trivially be provided
in the pure socket interface and easily created using tools like
boost::signals or boost::function.
** Thread Pool For
On Mon, 2002-11-25 at 10:30, Markus Schöpflin wrote:
And I think it would be really important to provide a clean
interaction model between the socket library and the thread library
and a clean solution to the problems that keep on coming up again and
again when doing socket programming.
Hu Xinwei wrote:
- How to interupt a thread waiting on some socket event
(synchronous and asynchronous) from another thread?
IMHO, I dont think such a mechanism is needed.
A typical example: You have a thread that implements a synchronous
listener like this:
bind();
listen();
while (true)
Hu Xinwei wrote:
- How to interupt a thread waiting on some socket event
(synchronous and asynchronous) from another thread?
IMHO, I dont think such a mechanism is needed.
A typical example: You have a thread that implements a synchronous
listener like this:
bind();
listen();
while
Pavol,
On Sun, 24 Nov 2002 10:12:36 +0100, Pavol Droba [EMAIL PROTECTED] wrote:
Is there an interest to support also non-TCP/IP based protocols like
IRDA/TP or raw sockets?
I think this should be feasable, though I know nothing of IRDA/TP.
Is it just a case of using the appropriate
Hu Xinwei wrote:
It is surprisingly difficult to portably tell this thread that it
should terminat itself.
Well, the portable method I know is like this:
listen thread:
for (;;) {
fd = accept();
if(server_should_shutdown) {
//do something here then exit
}
//process fd here
}
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Markus Schöpflin
Sent: Monday, November 25, 2002 11:30 AM
To: [EMAIL PROTECTED]
Subject: [boost] Re: Sockets
[...]
- How do you wait for more than just socket events? Thread conditions,
window
On Mon, Nov 25, 2002 at 04:09:29PM +, Hugo Duncan wrote:
Pavol,
On Sun, 24 Nov 2002 10:12:36 +0100, Pavol Droba [EMAIL PROTECTED] wrote:
Is there an interest to support also non-TCP/IP based protocols like
IRDA/TP or raw sockets?
I think this should be feasable, though I know
Not sure if this point is within the scope of current socket design:
Should the functionality be a very thin wrapper over the OS calls only?
E.g, in win32, blocking sockets especially within a GUI application behaves
erratically. A common way is to use to use non-blocking sockets and use
timed
On Sat, 23 Nov 2002 11:18:24 -0700, Jeff Garland [EMAIL PROTECTED]
wrote:
I see you have already captured Beman and
others prior work. I have added a references page for pointers to
other C++ socket libraries and other references as well as a few
other quick thoughts. See
Jeff,
Thanks. As regards times, we should definitely be using the time_duration
from boost date_time!
Yes, but we'll need to do something with the core. If you just used
posix_time::time_duration out of the box it is a bit of a heavy
dependency for the need.
Would you have any code
On Sat, 23 Nov 2002 14:23:37 -0600, Rob Tougher [EMAIL PROTECTED] wrote:
Where should I post these?
Wherever you see fit :-)
I would suggest the mail list for discussion, and the wiki for
capturing points that you don't wan't to get lost.
___
35 matches
Mail list logo
