hey, there As for the socket in C++, what's the most popular library you're using? C socket works but it's kind of cumbersome. I heard boost.org is trying to developing one. But seems not available yet. So, is there a "standard one" out there people are using?Thanks!

QuoteOriginally posted by: commonwealhey, there As for the socket in C++, what's the most popular library you're using? C socket works but it's kind of cumbersome. I heard boost.org is trying to developing one. But seems not available yet. So, is there a "standard one" out there people are using?Thanks! Sockets and more

btw: The following books cover the socket library. The first has 2 chapters and the second has 1 chapter. Though the products does have excellent documentation.C++ Network Programming, Volume I: Mastering Complexity with ACE and Patternsor ACE Programmer's Guide, The: Practical Design Patterns for Network and Systems Programming

I agree with dibble's recommendation - ACE is excellent and battle-tested.Boost.Asio was accepted for inclusion in future boost versions, but will probably not be out until 1.35 at the earliest. A draft version is available in the boost vault:boost_asio

Thanks for the input. ACE seems to be an opensource library developed by a university. It might not be widely adopted in industry, I guess. What are the most trading systems using for socket programming? Are they using those unix systems calls like, socket(), bind(), accept() etc ??? These demand much effort to program but should be much more reliable.

When you mention socket(), bind(), accept(), etc... you are referring to bsd sockets. Any library which you are going to use, will use bsd sockets. These calls will most likely be wrapped up in a nice API to simplify things for you. ACE handles all of the little issues which if you aren't aware of will cause you several hours to solve. There are several different APIs for distributed computing TIBCO, Spread, ACE, etc... Alot of places will use their own wrapper classes for bsd sockets.If you are not familiar with using bsd sockets and threading then I would suggest that you use something like Spread or ACE because you will be able to get your application up and running alot quicker than if you tried to implement your own socket API.

ACE has a big user community which includes industry and finance:Here are three finance examples from the previous link:"ACE is used for a global limiting system at Credit Suisse, Zurich, Switzerland.""Bear Stearns utilizes ACE in Risk Analysis Control System (RACS) to facilitate its server/client UNIX/NT development. ...""Merrill Lynch options trading desk are using ACE Reactor for point to point communication. Our system is a multi-tier architecture which uses both publish/subscribe and point to point."

We're using ACE and just started using the less bulky libevent.

QuoteOriginally posted by: QuantBitWe're using ACE and just started using the less bulky libevent.I just had a quick look at libevent. When you say it is less bulky, do you mean that it has a lot less bells and whistles, but it does have the bells and whistles than you need. Or do you mean that the performance is better.It looks like they have generalized the asynchronous "select()" system call. Is there more to it.

Thanks for your precious comments. I did a lot of BSD socket programming one year before, like using blocking, unblocking socket, select() and multithreading(pthread), multi processes to build scalable servers. I could definately use BSD socket withoug any problem. But, since I'm doing my thesis project, I want to know which is the way to go. In the employ's perspective, will they value the BSD socket programming skills more or they like to see the familarity with certain package like ACE. Thanks again!

QuoteOriginally posted by: dibbleQuoteOriginally posted by: QuantBitWe're using ACE and just started using the less bulky libevent.I just had a quick look at libevent. When you say it is less bulky, do you mean that it has a lot less bells and whistles, but it does have the bells and whistles than you need. Or do you mean that the performance is better.It looks like they have generalized the asynchronous "select()" system call. Is there more to it.Re ACE: Yes, we're basically only using Reactor and Acceptor/Connector/Svc_Handler. And even Svc_Handler is overblown for us as we only do single threading. We didn't have any performance problems with ACE so far.Re libevent: We didn't do measurements ourselfs but on their published performance graphs libevent looks much faster for applications with lots of connections on systems where epoll or kqueue are available.

QuoteIn the employ's perspective, will they value the BSD socket programming skills more or they like to see the familarity with certain package like ACE. I'd say a basic understanding of BSD sockets is always necessary. This was so in the RPC days and I don't see why it should have changed. When your networking framework fails unexplainably, and it will from time to time, you will have to look at socket and TCP/IP level.Given this basic understanding, familiarizing with any particular framework should be moderately easy. If you have the time, I would also recommend to play a bit with a framework of your choice so you get a feel.

For the record, I just noticed ACE also supports Linux's epoll, albeit with the still experimental Dev_Poll_Reactor. EDIT: I just checked with the developers. Here's what they say:QuoteACE_Dev_Poll_Reactor is fully functional and supported with Linuxepoll. It has not been as well exercised with /dev/poll.

Even if you are not interested in using ACE, have a look at its design. ACE is basically C++ implemention of POSA2 patterns described in the book "Pattern Oriented Software Architecture - Volume 2". You will get some idea about how to use the system calls like socket, bind, connect, accept etc.