Angus Leeming wrote:

...

There hasn't been much talk about a socket library recently. The Wiki stuff about sockets is quite old so I don't know if Hugo is still working on it?

He is. Slowly. http://giallo.sf.net Angus

Do you know that he still is? The last CVS commits there are 4 months old, apparently... Matt

I haven't heard much from Hugo Duncan since. I don't know how far giallo is from completion either. I'm still holding on to what I've been thinking about with demultiplexing of system events, and it keeps coming up occasionally. However, like Ducan, I'm starved for time. I will have more time in a month, when the semester at my university ends. In any case, I'd gladly trade volunteer work for something more reasonable any day. :) Aaron W. LaFramboise

Caleb Epstein wrote:

On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris@gtemail.net> 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

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/A... 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/A... 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

[...]

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@gtemail.net> 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/A...

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/A... 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

On Fri, 2005-03-04 at 16:42 -0500, Caleb Epstein wrote:

* 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've been using some custom classes to manage sockets as streams, and they proved to be very useful, simplifying the communication a lot. Maybe this functionality could be available, but only when the underlying socket is blocking (at least until Boost.Iostreams supports asynchronous operation). -- Julio M. Merino Vidal <jmmv84@gmail.com> http://www.livejournal.com/users/jmmv/ The NetBSD Project - http://www.NetBSD.org/