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