Re: [Boost-Users] Boost Sockets
At 07:08 PM 7/15/2002, James Zappia wrote:
Is there a boost library for network sockets on the radar?
Faintly. Several developers have done a certain amount of work, but I don't think the effort is very active at the moment.
Most of the C++ socket libraries I've seen aren't very appealing.
That's also my impression.
Just curious if boost will be offering something.
It is definitely on the wish list. --Beman
Can I add my voice to the list of very interested parties? :-)
On my current project we ended up using a low level api wrapper and building
our own higher level wrapper on top. But it was all pretty common stuff.
Unfortunately what we have done now is under company IPR (although it would
need extra work to be boostifed anyway).
A sockets library would definitely be very welcome.
Also, I believe it would be a necessariy groundwork for some of the higher
level thread library related proposals for further down the line.
[)o
IhIL..
----- Original Message -----
From: "Beman Dawes"
At 07:08 PM 7/15/2002, James Zappia wrote:
Is there a boost library for network sockets on the radar?
Faintly. Several developers have done a certain amount of work, but I don't think the effort is very active at the moment.
Most of the C++ socket libraries I've seen aren't very appealing.
That's also my impression.
Just curious if boost will be offering something.
It is definitely on the wish list.
--Beman
Info: http://www.boost.org Wiki: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl Unsubscribe: mailto:boost-users-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
"Phil Nash"
Can I add my voice to the list of very interested parties? :-) On my current project we ended up using a low level api wrapper and building our own higher level wrapper on top. But it was all pretty common stuff. Unfortunately what we have done now is under company IPR (although it would need extra work to be boostifed anyway). A sockets library would definitely be very welcome. Also, I believe it would be a necessariy groundwork for some of the higher level thread library related proposals for further down the line.
Is boost going to start treading on the toes of ACE with these libraries? I don't mind, its always nice to have a choice, but ACE already provides these libraries, and most of the other boost libraries seem very different to what ACE provides so why not stay that way? I'm quite happy to use both libraries in our projects. Cheers Russell
Is boost going to start treading on the toes of ACE with these
At 05:09 AM 7/16/2002, Russell Hind wrote: libraries?
I don't mind, its always nice to have a choice, but ACE already provides these libraries, and most of the other boost libraries seem very different to what ACE provides so why not stay that way? I'm quite happy to use both libraries in our projects.
Those are worthwhile questions. When a new library first comes up for discussion on Boost, it is very helpful if someone says "such-and-such an existing library already does a good job with that" or maybe "such-and-such an existing library already does that, but has the follow problems...". My sense with ACE is that while Boost developers know it exists, they usually aren't regular ACE users, and so have trouble judging the pros and cons. Have you used the ACE sockets and related facilities in real code? What was your experience? Does the ACE TCP/IP stuff mix well with other libraries? Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code? --Beman
[Beman]
Those are worthwhile questions.
When a new library first comes up for discussion on Boost, it is very helpful if someone says "such-and-such an existing library already does a good job with that" or maybe "such-and-such an existing library already does that, but has the follow problems...".
ACE Sockets exists but has the following problems.... er.. how long have you got? :-) (Ok, I'm exaggerating - but read on....)
My sense with ACE is that while Boost developers know it exists, they usually aren't regular ACE users, and so have trouble judging the pros and cons.
We tried and tried and tried to use ACE in out project - but all we wanted from it was the sockets library. Unfortunately ACE doesn't work this way. If you start using a bit of ACE you pretty much have to use all of it. It's similar to, say, MFC. It's a framework within which you have to do things its way. And the style is very "basic" (in order to be as portable as possible). In the end we looked around for something else and opted for a library that, although not as complete as ACE, didn't make us pay for the rest of it! I see this as a great strength of boost: 99% of the time You Only Pay For What You Use! That's why I would dearly love to see a sockets library in boost (if my current workload clears up soon I may even be able to contribute to its development). I have not been able to find a usable sockets library that fulfills the YOPFWYU mantra yet. I appreciate that there are problems with this as a comprehensive sockets library is an synergy of so many platform dependant entities. However I think if an approach similar to that use by boost.threads was taken then it is an achievable goal. As I mentioned in my previous mail, there is a higher level point where a sockets library could meet with the threads library to provide implementations of pattern level entities - in a manner similar to ACE - but without the overhead of paying for a framework (and with the benefit of more modern C++ style and techniques).
Have you used the ACE sockets and related facilities in real code? What was your experience?
Like I said, we tried! That said, we are using ACE elsewhere - as the foundation for the TAO implementation of CORBA. However we have fully encapsulated that and isolated it from everything else through strict compile time and run time boundaries - and we still regularly have problems with it.
Does the ACE TCP/IP stuff mix well with other libraries?
No, no, no no! :-)
Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code?
Yes! Have I made my position clear :-) [)o IhIL..
B. Dawes wrote:
My sense with ACE is that while Boost developers know it exists, they usually aren't regular ACE users, and so have trouble judging the pros and cons.
P. Nash wrote:
We tried and tried and tried to use ACE in out project - but all we wanted from it was the sockets library. Unfortunately ACE doesn't work this way. If you start using a bit of ACE you pretty much have to use all of it. It's similar to, say, MFC. It's a framework within which you have to do things its way.
While I agree with this to some extent, I think it this is exaggerated. To maximize portability, ACE defines an OS portability layers that abstracts the higher layer functions from the OS idiosyncrasies. No question you can't use ACE without depending on this layer. Boost has similar mechanisms but not as extensive as ACE. Is your complaint with the acceptor/connector/reactor patterns used in the implementations? So mostly I see the cost of ACE as the diskspace for all the ACE features I'm not going to use on my project (eg: reliable UDP protocol implementation). Of course, since a typical project will only use some of the Boost libraries the same issue applies to Boost. P. Nash wrote:
And the style is very "basic" (in order to be as portable as possible).
Please define 'basic'? ACE actually employs a policy-based design which many wouldn't consider 'basic'. P. Nash wrote:
but without the overhead of paying for a framework (and with the benefit of more modern C++ style and techniques).
ACE has used policy-based design and patterns for years -- so I think it is not modern C++ style that is lacking. That said, one area where ACE is weaker is use and integration with the C++ standard library. Since ACE preceded the standard library it has plenty of code for collections, strings, etc that could now be just use the standard library. Another area that has been discussed on the Boost list before would be to integrate better with the C++ I/O framework. This would be a benefit because it should be easier for C++ programmers to learn and the C++ I/O framework would be forced to adapt to address reactive programming styles. B. Dawes wrote:
Have you used the ACE sockets and related facilities in real code? What was your experience?
Yes on several projects across several platforms. Positive results overall. I don't remember us ever having a critical bug related to ACE. My main complaint with ACE is that it is fairly hard to learn due to somewhat sparse user documentation and a complex implementation domain. IME, this is hardly unique to ACE. It often usually requires as much intellectual effort to learn a framework to avoid writing code as it takes to actually write code. On at least one project we had a consulting company that produced an ACE training course to help developers understand how to apply ACE. P. Nash wrote:
That said, we are using ACE elsewhere - as the foundation for the TAO implementation of CORBA. However we have fully encapsulated that and isolated it from everything else through strict compile time and run time boundaries - and we still regularly have problems with it.
Such as?
Does the ACE TCP/IP stuff mix well with other libraries?
No, no, no no! :-)
Sure, it works fine with other libraries. What other libraries were you prevented from using by using ACE?
Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code?
See above... Jeff
That said, one area where ACE is weaker is use and integration with the
library it has plenty of code for collections, strings, etc that could now be just use the standard library. Another area that has been discussed on the Boost list before would be to integrate better with the C++ I/O framework. This would be a benefit because it should be easier for C++ programmers to learn and the C++ I/O
C++ standard library. Since ACE preceded the standard framework would be forced to adapt to address reactive
programming styles.
This was my main thought when I posted the question originally. Boost seems like an extension to the standard library, where as much (the parts I've looked at briefly) seem like OS dependent areas C++ doesn't touch. Threading, processes, shared memory, communications between these etc I haven't spent much time with boost either, so my impressions of what it and boost covers may be wrong. Russell
Jeff (et al)... I wrote a very long reply to this thread yesterday, just before I went home. However my pc crashed just before I had a chance to send it and I have not had the energy to rewrite it yet :-( As I am feeling a little "under the weather" today I don't know if I will get round to redoing it, so I thought I'd at least send this to let you know I am not ignoring you :-) [)o IhIL..
Have you used the ACE sockets and related facilities in real code? What was your experience?
Does the ACE TCP/IP stuff mix well with other libraries?
Are there a lot of dependencies between the ACE TCP/IP stuff and other ACE code?
We haven't actually used ACE. I have recently been playing about with the threading parts of it but we currently have inhouse code for threads and sockets etc (we currently only develop on Win32) so I can't give any opinions on it either way on the pros and cons of an particular parts of ACE. Russell
Beman Dawes wrote:
My sense with ACE is that while Boost developers know it exists, they usually aren't regular ACE users, and so have trouble judging the pros and cons.
That surprises me somewhat - since writing "platform-independent" multi-threaded code was the reason while in at least three projects I was working at ACE was used. As Jeff Garland writes, the only /drawback/ was "the cost of ACE as the diskspace for all the ACE features I'm not going to use on my project". But having threads, processes, *IPC and shared memory*... in one relieable and performant free framework with quite an amount of nice patterns and good documentation (this is the only point I'm disagreeing with Jeff Garland, see www.cs.wustl.edu/~schmidt/PDF/ACE-tutorial.pdf for an introductionary example). But of course, that was before the advent of boost threads and boost sockets:-) But I think both libraries' implementors should know this framework - it might be of help. Ali
participants (5)
-
Albrecht Fritzsche -
Beman Dawes -
Jeff Garland -
Phil Nash -
Russell Hind