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