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 Extensib
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 dis
> 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
> -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
> 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 wil
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 ground
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 th
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 controversia
EMAIL PROTECTED]> To: [EMAIL PROTECTED]
Sent by: cc: [EMAIL PROTECTED]
boost-bounces@list Subject: [b
...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 consid
> >> [...]
> >> 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
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 a
On Thursday, February 13, 2003, at 12:08 PM, Jason House wrote:
* How easy will support for SCTP be to work into the boost socket
library? ... and how easy would the interface be to use?
I looked at the docs on www.sctp.de and downloaded the source, and the
fatal flaw seems to be what I found
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 enco
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 gue
> -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 ide
>> 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
>> is the big picture. As far as there are no ideas of how to get a
>> reasonable model which inco
"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 mi
> -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
; stream protocol). If the generic
> socket library supported SCTP, would that meet your requirements?
>
>
> Jason House
> <[EMAIL PROTECTED]> To: [EMAIL PROTECTED]
> Sent by:
[EMAIL PROTECTED]
Sent by: cc:
boost-bounces@list Subject: [boost] Re: Sockets
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
> 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
> 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 woul
>> Sockets seems to be actively under development at the moment.
Most of
>> the activity seems to be on the Wiki at the moment though:
>>
>> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
>
>Ah!
>
>Yes, that looks more promising.
>
>Thanks for the redirect!
And mor
"Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>...
> "Blue, Reginald V" wrote:
>
> Sockets seems to be actively under development at the moment. Most of
> the activity seems to be on the Wiki at the moment though:
>
> http://www.crystalclearsoftware.com/cgi-bi
"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
Sockets seems to be actively under development at the moment. Most of
the activity seems to be on the Wiki at the moment though:
http://www.crys
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
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
> From: Hugo Duncan [mailto:[EMAIL PROTECTED]]
> 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.
>
> -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 e
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
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 sockad
>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();
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 (t
Hi boosters:
>Eric Woodruff wrote:
>
>> * 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.
>>
>> ** Thre
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.
Eric Woodruff wrote:
> * 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 event-driv
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 op
Thorsten,
On Sat, 23 Nov 2002 23:57:56 +0100, Thorsten Ottosen <[EMAIL PROTECTED]> wrote:
> socket_base::initialise();
>
> socket.close();
> socket_base::finalise();
>
> Why doesn't this happen in the constructor/destructor of some object?
Basically because I am not sure of the requirement
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.
___
Un
> 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 r
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
>
> htt
43 matches
Mail list logo
