[network] Boost.Network proposal v0.2
Fellow Boosters, this is an update on my proposal for a Boost.Network library, located in the Sandbox. The file is called network.tar.bz2 or network.zip, located in the pedro_lamarao folder. The library was downloaded by a few people; I'd like to talk to you if you actually tried to use it. The layout of the archive is the familiar boost directory layout, ready to be expanded on top of a boost release. It was worked on a CVS HEAD version of boost. Every new name was added into a boost::network namespace. Every file is licensed under the Boost License; I've already secured the copyright over the code with my employer, pending the formality in paper. BoostBook documentation is provided with a Jamfile.v2 for bjam, but with many sections still empty. There is currently a Tutorial and an Overview of the library; the References section is still just a skeleton. The documentation can be found here: http://mndfck.org/~pedro.lamarao/projects/boost_network/ The header layout is now more closely what I think should be in a formal proposal for standard networking IOStreams. Comments on this would be much appreciated. Examples are provided in subdirectories of the libs/example/ directory, each with a Jamfile for bjam. These examples are still far from what I think is possible to achieve, but already show some interesting coding patterns facilitated by the IOStream interfaces. The examples include: - Spirit based internet::abnf class, containing the standard ABNF rules; - Spirit based internet::uri class; - std::getline based http_response class; - Spirit based irc::message class; - threaded servers for the chargen, daytime, discard, echo, qotd and time protocols. Yes, I forgot to add license notes in every example file. I'll correct that in the next days. I'll complete the examples with an smtp_client application, based on an internet::message and an internet::smtp_transaction, and a length-prefixed "binary" protocol. The implementation of the IOStreams does no buffering or code conversion: this is the simplest case, and offers the worst performance possible by making a system call for each byte read from the network. On a fast machine with a 256 kbps link the overhead is difficult to notice; slower machines and/or faster links make it more evident. Adding buffering is easy, though, as I've done it before; I could throw a quick patch for someone interested in benchmarking it. Code conversion is trickier. -- Pedro Lamarão
Thorsten Ottosen wrote:
Hi Pedro,
Fellow Boosters,
this is an update on my proposal for a Boost.Network library, located in the Sandbox.
I just wanted to say that it starts to look good.
Keep up the good work...I'm looking forward to a review in the near future.
It sure gives me a little more energy to know there *are* people interested in this library... :-) -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Pedro Lamarão wrote:
Thorsten Ottosen wrote:
Hi Pedro,
Fellow Boosters,
this is an update on my proposal for a Boost.Network library, located in the Sandbox. I just wanted to say that it starts to look good.
Keep up the good work...I'm looking forward to a review in the near future.
It sure gives me a little more energy to know there *are* people interested in this library... :-)
I'm definitely interested, too. If there's not substantial progress on networking soon, I'm planning to implemement my own socket devices for the Iostreams library; of course I'd switch to using Boost.Network whenever it becomes available. The reason I haven't commented yet is that I'm way behind on reading the large volume of network-related messages in the archives. Jonathan
Jonathan Turkanis wrote:
Pedro Lamarão wrote:
Thorsten Ottosen wrote:
Hi Pedro,
Fellow Boosters,
this is an update on my proposal for a Boost.Network library, located in the Sandbox. I just wanted to say that it starts to look good.
Keep up the good work...I'm looking forward to a review in the near future.
It sure gives me a little more energy to know there *are* people interested in this library... :-)
I'm definitely interested, too.
If there's not substantial progress on networking soon, I'm planning to implemement my own socket devices for the Iostreams library; of course I'd switch to using Boost.Network whenever it becomes available.
I'm particularly interested in the above combination. Jeff Flinn
Jonathan Turkanis wrote:
It sure gives me a little more energy to know there *are* people interested in this library... :-)
I'm definitely interested, too.
If there's not substantial progress on networking soon, I'm planning to implemement my own socket devices for the Iostreams library; of course I'd switch to using Boost.Network whenever it becomes available.
What kind of "socket device" do you need? What do you plan to do with it? Maybe we can work something out. I'm trying to address as many use cases as I can. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
"Pedro Lamarão" <pedro.lamarao@intersix.com.br> wrote in message news:42CC15A3.8040208@intersix.com.br...
It sure gives me a little more energy to know there *are* people interested in this library... :-)
Don't worry, there is great interest in a networking library, and your stuff looks good. Although I'm not qualified to comment on details of your design. There has been a lot of discussion of networking issues in the past, but that hasn't resulted in an actual proposed library. My guess is that people are holding their breath, hoping that your work will be carried through to completion. One thing I didn't see was a discussion of the various levels of networking support. Are the components you describe actually implemented in terms of some lower level functionality? Will that lower level be publicly exposed? Thanks, --Beman
Beman Dawes wrote:
One thing I didn't see was a discussion of the various levels of networking support. Are the components you describe actually implemented in terms of some lower level functionality? Will that lower level be publicly exposed?
We must, of course, eventually reach the operating system. So in a minimalist implementation the streambuf type would contain a socket descriptor and make system calls. It being a template, my decision was to move these, the descriptor and the system calls, into another class, non templated, to be able to hide those inside a library. So, yeah, there is a "socket" type around. It is inevitably accessible, but my intention is to not document it as one of the library's facilities. It's sole purpose is to not show people system calls in header files, and, together with other machinery, completely avoid the system header files where those are declared. I've recently written something about the NetworkAddress concept, and why it exists; I'm now moving to summarize and address some of the points people brought up last time we had a big [network] thread. I think I can categorize those under two bullets: * non-blocking operation mode * primitive operation mode * binary IO The argument for the availability of both is "performance". I'm positive we have no need for "primitiveness" for performance. I suspect a non-blocking operation mode is less useful than the amount of requests would suggest (although, of course, *useful*). For the meaningful values of "binary", IOStreams support "binary" IO just fine. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
On 7/7/05, Pedro Lamarão <pedro.lamarao@intersix.com.br> wrote:
So, yeah, there is a "socket" type around. It is inevitably accessible, but my intention is to not document it as one of the library's facilities.
The discussions about a networking library here in the boost mailing list, IIRC, people defined that a lower-level abstraction was a need. And I think it really is. Would be very helpful to have RAII with sockets without needing to reimplement it every time. As is needed to be able to use completion ports or async IO with networking, that wont be available in your library. (or am I missing something?) best regards, Felipe -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Felipe Magno de Almeida wrote:
The discussions about a networking library here in the boost mailing list, IIRC, people defined that a lower-level abstraction was a need. And I think it really is. Would be very helpful to have RAII with sockets without needing to reimplement it every time. As is needed to be able to use completion ports or async IO with networking, that wont be available in your library. (or am I missing something?)
The library I'm preparing to propose is a networking implementation of the standard IOStream interfaces with the necessary accessories to allow proper usage. To achieve that purpose, I not only have no interest in dealing in terms of descriptors, but no inspiration: fstreams don't do it. No types proposed by the library are meant to interact with this or that operating system primitive. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
Pedro Lamarão wrote:
Felipe Magno de Almeida wrote:
The discussions about a networking library here in the boost mailing list, IIRC, people defined that a lower-level abstraction was a need. And I think it really is. Would be very helpful to have RAII with sockets without needing to reimplement it every time. As is needed to be able to use completion ports or async IO with networking, that wont be available in your library. (or am I missing something?)
The library I'm preparing to propose is a networking implementation of the standard IOStream interfaces with the necessary accessories to allow proper usage.
To achieve that purpose, I not only have no interest in dealing in terms of descriptors, but no inspiration: fstreams don't do it.
Then I strongly suggest you rename your library to Boost.Socketstreams or something similar. We had a lot of discussions about goals and requirements which are summarized in the Wiki. I appreciate your interest in creating a socketstreams library but it's just a part of a network library. There are people who have no interest in socketstreams but look for other concepts to create network applications. We shouldn't argue their needs away. However that all doesn't mean that I don't look forward to see you going on with your library! Boris
On 7/8/05, Boris <boris@gtemail.net> wrote:
Pedro Lamarão wrote:
Felipe Magno de Almeida wrote:
The discussions about a networking library here in the boost mailing list, IIRC, people defined that a lower-level abstraction was a need. And I think it really is. Would be very helpful to have RAII with sockets without needing to reimplement it every time. As is needed to be able to use completion ports or async IO with networking, that wont be available in your library. (or am I missing something?)
The library I'm preparing to propose is a networking implementation of the standard IOStream interfaces with the necessary accessories to allow proper usage.
To achieve that purpose, I not only have no interest in dealing in terms of descriptors, but no inspiration: fstreams don't do it.
Then I strongly suggest you rename your library to Boost.Socketstreams or something similar. We had a lot of discussions about goals and requirements which are summarized in the Wiki. I appreciate your interest in creating a socketstreams library but it's just a part of a network library. There are people who have no interest in socketstreams but look for other concepts to create network applications. We shouldn't argue their needs away. However that all doesn't mean that I don't look forward to see you going on with your library!
IMO, renaming the library to socketstreams would avoid a lot of confusion and boost cant have two libraries with the same name. So, having a Network library without a lower level abstraction, nor async IO, would be very restrictive to all the users that could be addresses by a network library. However, a socket stream library is, IMO, very useful and helps a lot, and makes it a lot easier to write a synchronous network program. But it has its limitations... mainly concerned with performance. I think it is a very good step forward to have a complete network library in boost, either. best regards Felipe.
Boris
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
Boris wrote:
Then I strongly suggest you rename your library to Boost.Socketstreams or something similar.
That, of course, fine. Thinking about it, there are already two namespaces containing stuff related to IOStreams, boost::io and boost::iostreams. It's probably unecessary to have another one. Maybe all these should just be put together. But one proposal at a time. -- Pedro Lamarão
I agree, but it would be more immediately compelling if the impressive examples provided some sample output(s) so we can quickly see it in action. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen | Sent: 06 July 2005 17:13 | To: boost@lists.boost.org | Subject: Re: [boost] [network] Boost.Network proposal v0.2 | | Hi Pedro, | | > | > Fellow Boosters, | > | > this is an update on my proposal for a Boost.Network library, | > located in the Sandbox. | | I just wanted to say that it starts to look good. | | Keep up the good work...I'm looking forward to | a review in the near future. | | br | | -Thorsten | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
Paul A Bristow wrote:
I agree, but it would be more immediately compelling if the impressive examples provided some sample output(s) so we can quickly see it in action.
Well... The "client" examples throw stuff to cout, and the "server" examples are primitive Internet protocols usable with telnet. What kind of sample output are we talking about? A step by step "verbose" mode? -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
I had in mind some samples of 'stuff' sent to cout, including the input arguments if appropriate. You could follow many other Boost examples and add the output at the end of the examples as a comment: /* Output is: ... ... */ This avoids having to build the code to try it or confirm ones understanding of what the examples do(though this could be a good idea if looking at it in detail of course). (The intro is good). Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Pedro Lamarão | Sent: 07 July 2005 20:50 | To: boost@lists.boost.org | Subject: Re: [boost] [network] Boost.Network proposal v0.2 | | Paul A Bristow wrote: | | >I agree, but it would be more immediately compelling if the | impressive | >examples provided some sample output(s) so we can quickly | see it in action. | > | > | Well... The "client" examples throw stuff to cout, and the "server" | examples are primitive Internet protocols usable with telnet. | | What kind of sample output are we talking about? | A step by step "verbose" mode? | | -- | Pedro Lamarão | Desenvolvimento | | Intersix Technologies S.A. | SP: (55 11 3803-9300) | RJ: (55 21 3852-3240) | www.intersix.com.br | | Your Security is our Business | | | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
Paul A Bristow wrote:
I had in mind some samples of 'stuff' sent to cout, including the input arguments if appropriate.
You could follow many other Boost examples and add the output at the end of the examples as a comment:
/*
Output is:
... ...
*/
This avoids having to build the code to try it or confirm ones understanding of what the examples do(though this could be a good idea if looking at it in detail of course).
(The intro is good).
Well... Yeah, I could do that. I'm planning on a documentation section about the examples provided (and the techniques used), so, maybe example output would fit there too. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business
participants (9)
-
Beman Dawes -
Boris -
Felipe Magno de Almeida -
Jeff Flinn -
Jonathan Turkanis -
Paul A Bristow -
Pedro Lamarão -
Pedro Lamarão -
Thorsten Ottosen