----- Original Message ----- From: "Boris" <boris@gtemail.net> To: <boost@lists.boost.org> Sent: Monday, March 14, 2005 12:38 PM Subject: [boost] Re: Re: Sockets: proposal for a library design [snip]
I don't know who wrote the socket requirements. I just felt that I shouldn't ignore them. If there are any other requirements I would be happy to hear them. Eg. it seems like we found a new requirement these days as several people dislike the idea of a I/O streams based network library. I/O streams support seems to be desired only on a higher level?
[...] Perhaps a reason that noone has designed a really great sockets library yet is that there is little practical reason to, as BSD sockets is probably more portable (from a practical standpoint) than a Boost library will ever be, and libraries try to that "abstract" it have done nothing but get in the way.
Most developers probably make a decision which I/O model they want to support and forget about the rest. As there are four I/O models it doesn't make much sense if they are implemented by different developers again and again. This should be a very good reason to create a C++ network library.
Boris
Hi, I too find the models confusing and believe that confusion to be avoidable. Adoption of I/O streams is also an intellectual struggle and (again) a struggle that may be avoidable. Networking is inherently asynchronous. Initiation and acceptance of connections and I/O may be disguised as synchronous but other activity (e.g. "network down") cannot. Network APIs will often defer such errors until the next reporting opportunity (e.g. next I/O request) but this is a band-aid that is sometimes enough and at other times downright misleading. I assume that something going by the name of Boost.Net would be targeting a higher sophistication. Proposing that all network communication is asynchronous does not preclude any synchronous coding. As discussed in other threads (i.e. RPC) a "low-level", asynchronous library may be the "core" of a Boost.net while synchronous services may be built on top. I have implemented this combination of "co-operating models" more than once and it has turned out OK (or better :-) One of the more recent challenges has been the integration of implementations of network libraries into different application frameworks - much pain involved. IMO the lack of a standard framework is holding back development of several Boost libs. Without some means to create co-operating components (e.g.sockets manager, GUI, file I/O and timers) the different parts become islands. This situation is perhaps soonest encountered around 3rd party frameworks and networking. I think an asynchronous, core Boost.Net should expose fundamental network services. In the case of TCP, that would be the reliable, async 2-way transfer of data blocks. Achieving a clean and portable library at this level would be achievement enough. Dragging I/O streams into the "network discussion" at this point is almost premature; it moves the focus up the network stack. Again this doesnt preclude those who need to from integrating with I/O streams at a later point. $0.01 Cheers, Scott