[network] Boost.Network proposal v0.4
Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the "Input - Output" folder of the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: * IOStreams through boost::iostreams (providing a "talker" type model of Device over sockets). * A listener class. * A wrapper for the name resolution services of the system library. * Types to store network addresses with formatted output operators. There's still some more documentation to write, though. Please give one last shot at this proposal. Last time people objected to it as a "Boost.Network" library for not being sufficiently generic (in which it doesn't support "multiplexing" or "asynchronicity"), so perhaps I should move it deeper inside, like, Boost.IOStreams.Network. What do you think? The four components provided could be considered independently: the listener class is as simple as it gets, with a private "accept" method for RAII initialization of whatever socket wrapper type; the model of Device is also as simple as it gets; maybe there is some other interesting stuff to improve the getaddrinfo wrapper and the address types. Possible areas of improvement for the future are: * selector/poller (which is sitting around here waiting) * full formatted input and output for address types * asynchronous resolver (based on Boost.Threads). * Wrapper for sendfile/TransmitFile. -- Pedro Lamarão
a very complete network library almost-ready for boost inclusion is already available check http://asio.sf.net Can you compare your proposal to asio, as it has already been discussed in this list On 11/4/05, Pedro Lamarão <pedro.lamarao@mndfck.org> wrote:
Fellow Boosters,
this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the "Input - Output" folder of the Sandbox.
I consider it feature complete for a 1.0 milestone; the features being:
* IOStreams through boost::iostreams (providing a "talker" type model of Device over sockets). * A listener class. * A wrapper for the name resolution services of the system library. * Types to store network addresses with formatted output operators.
There's still some more documentation to write, though.
Please give one last shot at this proposal.
Last time people objected to it as a "Boost.Network" library for not being sufficiently generic (in which it doesn't support "multiplexing" or "asynchronicity"), so perhaps I should move it deeper inside, like, Boost.IOStreams.Network. What do you think?
The four components provided could be considered independently: the listener class is as simple as it gets, with a private "accept" method for RAII initialization of whatever socket wrapper type; the model of Device is also as simple as it gets; maybe there is some other interesting stuff to improve the getaddrinfo wrapper and the address types.
Possible areas of improvement for the future are: * selector/poller (which is sitting around here waiting) * full formatted input and output for address types * asynchronous resolver (based on Boost.Threads). * Wrapper for sendfile/TransmitFile.
-- Pedro Lamarão
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jose wrote:
a very complete network library almost-ready for boost inclusion is already available check http://asio.sf.net
Can you compare your proposal to asio, as it has already been discussed in this list
I'll call my proposal iostreams_network while answering your request. Many different libraries have been exposed and discussed in this list in the past, including the iostreams_network one. Some differences from reading the reference: - asio is a new design for an IO library; iostreams_network adds networking to the IOStreams library (now based on Boost.IOStreams). - asio's design allows for "asynchronous" or "multiplexing" IO; iostreams_network adds simple blocking as usual for IOStreams. - asio adds a "smart buffer" machinery; iostreams_network reuses basic_streambuf. - asio adds many wrappers for socket options; iostreams_network hides all implementation-specific stuff. - asio is header-only; iostreams_network requires a DLL to hide platform-specific stuff. I'll try an run the examples in the next few days. I've been offlist for a while, getting back on track just now. -- Pedro Lamarão
participants (2)
-
Jose -
Pedro Lamarão