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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-23 19:02:27

Hi Boris,

> 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).

> 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
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
the right way to go. The abstraction I proposed makes this a
"trivial" task and one that does not require any extra detours for
the user's data (SSL is already slow enough<g>).

> 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?

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.

The library I propose does have features (ex: async callbacks) that
might/probably require threads on some platforms, because that is a
more "C++ way" to know what has completed within its appropriate
object context. I don't view this as adding any new networking
concepts any more than Winsock posting messages to an HWND for
read-complete would go beyond the spirit of sockets.

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
layers above. It is not clear (to me<g>) exactly what would be
required with the design on the Wiki.

Best regards,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com