[boost] Re: [network] An RFC - updated

From: Boris (boris_at_[hidden])
Date: 2005-04-24 10:50:17

Don G wrote:

Hi Don,

>> Blocking, non-blocking and select are three of
>> four I/O models. And I think we can support all
>> four I/O models on all platforms
>
> I agree that we _can_. I still don't see any reason for a select-like
> mechanism that is user facing. This is bookkeeping that is best left
> to the brokers behind the scenes. Peter's suggesting of a net::poll()
> or my more general approach (just hinted at really) are more than
> adequate and require no add/remove/who_services_this_socket_anyway
> issues. I would like to hear some convincing reasons for exposing
> behaviors that feel like select (beyond a certain low level).

again I agree with you. I wrote select() as you were talking about select() 
in Windows before. So I didn't write poll() or epoll() in order not to shift 
focus to implementation details. :) I agree with you that we shouldn't 
imitate functions from the C API but improve them.

>> If you are talking about level 1 of the network
>> library I agree with you. However it shouldn't
>> be any problem either to create a ssl_socket
>> derived from a socket class in level 0.
>
> What is a "socket" then as it relates to "socket class"? If the
> assumption is that it has a C API socket fd, then an ssl stream will
> not be a substitute for a socket. I guess I don't see how it can be

In level 0 I assume a socket to encapsulate a socket fd and provide methods 
to support the four mentioned I/O models. It should then be possible to 
derive another class, eg. ssl_socket and overwrite methods like accept() in 
order to verify the client. However I wonder about your ssl stream? Are you 
in level 0 or in level 1? ;)

> short of writing a man-in-the-middle SSL that creates a socket pair;
> one for it to read/write user data and the other so it can look and
> behave like a socket. If this is the approach, I don't think it is

I see you distinguish between read/write and socket! If I understand you 
correctly you don't expect any socket to provide read/write methods but 
return some kind of stream which is then used for reading and writing?

>> I see. So your library is as far as I understand a
>> mixture of level 0, level 1 and optional platform-
>> specific classes. If we can sort this out that
>> would be nice. ;)
>
> I'm not sure about the platform-specific classes, could you clarify?

The non-blocking/asynchronous I/O can be implemented in different ways. If 
you know that your target platform supports eg. kqueue and you have reasons 
to use kqueue the network library could offer such a platform-specific class 
to provide non-blocking/asynchronous I/O based on kqueue. At least I thought 
this is one goal of your library. However now after your question I am not 
so sure any more. ;)

> I view my proposal as a complete abstraction, encapsulation,
> virtualization of layer 0, so in that sense it could be viewed as a
> level 1 library, but not in the same sense as the Wiki docs. It makes
> every effort to expose as much of the capabilities and behavior of
> the underlying network (not to be confused with API) as possible:
> datagram, stream, broadcast, loopback, INADDR_ANY, multi-home (local
> and remote), address resolution (async as well as sync). More
> capabilities could be added in a similar spirit, such as
> multicasting. Some facilities may be only available for some network
> types, but they should still be described in a general way. One could
> take this approach for platform-specific features as well, but that
> has to be carefully weighed because it could lead to useful libraries
> that have limited portability for no good reason.

I see. I think I wrote in another thread that I view layer 0 as to be very 
close to the C API. The idea of layer 0 is (at least in my mind) that 
experienced network developers who know Berkeley sockets should be able to 
switch over very easily to the C++ network library - the entry level should 
be as low as possible. Your idea of level 0 seems to be something else?

> [...]
> Suppose, just for sake of discussion, that some platform exists that
> does not use sockets as its network API (as was the case for Mac OS
> pre-X). Using the approach I propose this would have no impact to all

How many platforms are there without Berkeley sockets? Do we really want 
*not* to provide a layer close to Berkeley sockets because of one (?) old 
platform and make it more difficult for the the majority of network 
developers to switch over to the C++ network library who know and understand 
Berkeley sockets?

Boris