On Wed, 14 Dec 2005 17:31:22 -0500 Stefan Seefeld <seefeld@sympatico.ca> wrote:
For me a 'socket class' is two things (let's ignore datagram sockets in this context): a way to create socket endpoints, as well as manipulate associated options, and on the other hand some means to read and write.
First, you can't ignore datagrams, as that is a large part of modern networking, especially in large data distribution systems. But, for the sake of conversation...
For the synchronous case I think this is nicely described by a streambuf / stream pair of interfaces. A 'socket_stream' class would allow to create socket endpoints, and set socket options. A socketbuf class would implement read and write operations.
I've looked at a ton of IOStream network implementations over the years. Two of my major problems with IOstreams for networking: error handling and performance (followed closely by several other issues). I've yet to see anything close to reasonable. For that matter, I've yet to see anything implemented with the IOStreams that isn't a problem for anything but the most simple applications. As soon as I see IOStreams, my antennae go crazy. Sure, it's a nice concept... I think it is appropriate to offer an IOStreams interface for those who desire such an interface. However, if that is the best way to use synch sockets in boost, I won't go near it. For many years, I have been in the business of very high performance, highly distributed network applications, and my paranoia is well placed ;-)
On the other hand, asynchronous I/O over sockets would be handled very differently. In fact, given that platforms provide quite different means to wait for readable data (say), I'm not even sure that the 'socket' concept should be discussed independently from the sync / async policy at all.
I can see your point.