Re: [boost] Re: Re: Sockets

From: Cory Nelson (phrosty_at_[hidden])
Date: 2005-03-06 01:54:07

Looking at the .NET async methods, they are using WSARecv() etc. 
Maybe those use a global completion port underneath it all?  If so,
where did you get the source for Winsock :P

Perhaps I should have been more clear.  When implementing completion
ports, in win32 at least, you aren't limited by callbacks for socket
functions but can also loosely manage your threads and push custom
messages to them.  I could understand why the custom messages might be
out of scope (though it is very useful) of Boost.Socket, but managing
the threads (even minimally, just to choose how much threads to start)
is a must.

On Sat, 5 Mar 2005 13:21:34 +0200, Boris <boris_at_[hidden]> wrote:
> Cory Nelson wrote:
> > 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.
> 
> If we accept two models - synchronous and asynchronous - the second one
> could be implemented with I/O completion ports if available. That's the .NET
> approach, and Microsoft's .NET implementation is based on I/O completion
> ports.
> 
> The socket class in .NET has two kinds of read/write-methods:
> - For synchronous access: Send() and Receive() (it depends on a property
> called Blocking if they block or don't)
> - For asynchronous access: BeginSend() and BeginReceive() (a delegate aka
> function pointer has to be passed to them which is then called when data is
> available)
> 
> Advantage of this interface is that there are really two kinds of I/O
> models. It depends on the implementation if asynchronous access is based on
> multiplexing, aio, I/O completion ports etc.
> 
> The AsynchSocketBase concept seems to be built on this idea:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/AsynchSocketBase
> 
> I like this idea as otherwise we end up with a socket class which has to
> provide read/write-methods for every I/O model. Eg. the
> AcceptorSocketConcept at
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/AcceptorSocketConcept
> has two accept() - one for blocking, one for non-blocking. If a socket class
> supports every I/O model explicitly it will get a fat interface.
> 
> Boris
> 
> > [...]
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

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