Re: [boost] Re: Sockets

From: Cory Nelson (phrosty_at_[hidden])
Date: 2005-03-05 01:26:24

Something .NET doesn't have (but Win32 and Linux do), is I/O
completion ports.  For a high-performance server app, they beat pretty
much everything.  It would be great to see this get into a boost
library, and trivial to implement them using select/poll in platforms
that don't support true completion ports.

On Sat, 5 Mar 2005 02:18:47 +0200, Boris <boris_at_[hidden]> wrote:
> Caleb Epstein wrote:
> > On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris_at_[hidden]> wrote:
> 
> Caleb, thanks for your comments! There is not much feedback so appreciate
> any comment. I wonder if there's a lack of interest or some resignation as
> the socket stuff is in the Wiki for ages without any progress.
> 
> > [...]
> > * blocking/nonblocking mode must be selectable at run-time.  Having a
> > default selectable at compile time is fine, but not allowing a switch
> > at runtime would be too limiting.
> 
> You are right, I agree.
> 
> > * Don't model sockets on iostreams.  They don't model non-blocking I/O
> > correctly (see Jonathan Turkanis's recent posting on the evolution of
> > the Boost.Iostreams interfaces).  Simple methods called read and write
> > should be sufficient.
> 
> I agree again. The operators in class socket are an example to show where
> read- and write-methods will be implemented (whatever they will look like).
>
> > * Server should probably be a factory of sockets.  I don't think
> > client and server should be concepts at the root of the hierarchy.
> 
> I'll have a look at the net library in Java and .NET. I hope to create UML
> diagrams for these libraries, too. Then we should get an insight into
> differences and possible advantages of their designs. I'll post to this
> newsgroup whenever I update the Wiki.
>
> > * To implement a scalable server-side application there must be
> > support for IO multiplexing (e.g. select/poll/etc) and this should be
> > considered in the design.
> 
> That's what the class multiplexing represents (in namespace
> boost::net::iomodel)?
> By the way, what do you think about the .NET way? In .NET there are only two
> models: synchronous and asynchronous. Synchronous is the same as blocking
> but asynchronous depends on the implementation (from multiplexing to
> signal-driven to real asynchronous is everything possible). Does it matter
> to a library user how asynchronous is actually implemented?
>
> > * Picking nits, they are "Berkeley" sockets, not "Berkely".
> 
> Thanks, corrected!
> 
> Boris
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
Cory Nelson
http://www.int64.org