19

I need to create a network server in C++ for a trading application. This network server needs to perform the following tasks:

  • handle authentication of clients and provide session id for each session.

  • handle orders originating from the clients and inform clients about their execution.

  • handle other data request asked for by the clients and send data back to them.

I am planning to use Boost.Asio networking library and Google protocol buffers to implement the messages being sent from the clients to the server. XML-RPC or SOAP based approaches are a strict no-no as latency is a big concern.

I have the following questions for the stackoverflow community:

  1. Is it a good idea to implement these messages using protocol buffers? I am also considering sending messages Boost serialization library to implement this. When I look at the code, I find myself more confident of implementing this with boost serialization and Google protobuf headers look too heavyweight. Which of these methods will be a) more maintainable and b) require less effort? I guess, both these approaches will work across different platforms.

  2. Is there any other networking library which I should look at apart from Boost.Asio.?I find ACE a little dated as far as C++ coding style is concerned.

  3. Eventually I would like to make this network server run on SSL, however, I do not have any experience with implementing SSL. How much effort would it require to move to SSL later on. Should I start with SSL or can it be added later on?

  4. Does anybody know of a good open source network project, which might have implemented a similar network server using Boost.Asio, to get inspired from?

Sam Miller
  • 23,808
  • 4
  • 67
  • 87
Lazylabs
  • 1,414
  • 16
  • 23
  • 1
    Take a look at [cpp-netlib](http://cpp-netlib.github.com/). – Ferruccio Oct 04 '11 at 18:14
  • 6
    You might want to think about including ssl sooner rather than later. I don't know of too many traders who will welcome all of their buy and sell orders revealed on the net. But I'm probably wrong: maybe it's just because the only traders I know are paranoid, suspicious, close-to-the-vest traders who wear wraparound shades and carry a loaded gun. – Pete Wilson Oct 04 '11 at 18:21
  • 1
    Some questions. How many clients will be connected to a server? Do the clients stay connected after performing a transaction? Why do you think SOAP will add too much latency? Which OS - Linux, Windows Server, or something else? – selbie Oct 04 '11 at 18:23
  • 1
    Yeah, definitely get SSL worked out sooner rather than later. – riwalk Oct 04 '11 at 18:26
  • Pete Wilson and Stargazer712: Thanks for your reply. – Lazylabs Oct 04 '11 at 18:26
  • @selbie I expect around a 1000 cients. Yes, the clients do stay connected until they log out. Regarding SOAP, I think parsing XML will be too expensive compared to what I can do with boost serialization or protobuf. OS - Linux. – Lazylabs Oct 04 '11 at 18:28
  • Just orders and executions? Any regional or composite quotes? Level 1/Level 2? Are you going to provide replay functionality? What message protocol are you going to use? FIX? Binary? FAST compression? Is your service going to be available via TCP or UDP? – John Dibling Oct 04 '11 at 18:30
  • 2
    How sensitive to latency are the clients? What is the expected bandwidth? What are you going to connect to on the backend? Are you going to provide time & sales? – John Dibling Oct 04 '11 at 18:31
  • @JohnDibling yes, just orders and executions. Market data will be handled by a separate component. Internal applications use FIX. But, this network server will probably use some kind of binary protocol only. It is TCP. – Lazylabs Oct 04 '11 at 18:32
  • 1
    Have you considered apache? Reinventing the wheel can be fun, but it takes years of development and review for software to become robust enough for enterprise use. – regality Oct 04 '11 at 18:59
  • @Lazylabs, why not FAST encoded FIX? then you don't have too much of a conversion overhead to your internal stuff. Or even FIX, it's well understood and can be pretty fast if you know what you are doing. – Nim Oct 04 '11 at 21:49
  • 1
    FIX/FAST can be extremely small on the wire if you know what you're doing. But do yourself a favor and get an encoder/decoder that already works because damn.... – John Dibling Oct 05 '11 at 00:02
  • @JohnDibling latency is important, but this is not a HFT application. This network server will connect to the a backend FIX application, which is based on Quickfix. But, thanks for your reply on FIX/FAST, that might be worth looking at. – Lazylabs Oct 05 '11 at 04:12
  • @Nim i have not looked at FAST yet, but it seems I should do that first, as you and John have mentioned. – Lazylabs Oct 05 '11 at 04:14
  • @regality going on HTTP is also a good idea, provided we can come up with a great API. Thanks. – Lazylabs Oct 05 '11 at 04:43
  • 1
    Here is a link to the FAST specification. Ver 1.2 is common in deployment. http://www.fixprotocol.org/fastspec – John Dibling Oct 05 '11 at 13:58
  • 1
    Consider also: You may not need any security protocol like SSH if your network is physically secure. – John Dibling Oct 05 '11 at 13:59
  • @JohnDibling Security is a concern, so I'll have to go for SSL. – Lazylabs Oct 05 '11 at 17:31

7 Answers7

4

You should also look at Apache Thrift (originated at Facebook) or Apache Etch (initially developed by Cisco). They are RPC frameworks that make it easy to develop both servers and clients meeting your needs (more or less). For a framework developed using protobuf and boost.asio, look at the server1 project.

npclaudiu
  • 2,401
  • 1
  • 18
  • 19
  • I should also mention [Ice by ZeroC](http://www.zeroc.com/index.html), which is a similar fully-featured framework, that supports protobuf serialization. It is available under the GPL v2 license or a commercial one. – npclaudiu Oct 12 '11 at 20:47
3

BSON ( http://www.mongodb.org/display/DOCS/BSON and http://bsonspec.org ) is a very fast binary protocol. C++ implementation is readily available from mongodb. The fact that it is basically JSON makes it quite easy to implement and maintain.

SSL implementation doesn't add up much extra code to the asio-based server: SSL context initialization with certificate paths and some handshake logic.

dimitri
  • 874
  • 8
  • 11
2

You should look into MessagePack http://msgpack.org/

rouzier
  • 1,160
  • 8
  • 19
1

I'm kinda late to the party - but I wanted to throw POCO (http://pocoproject.org/) into the ring as well. I wont say it is better than ASIO (because it isn't) but it is as good. And if you are not a template god - you will find POCO delightful. Definitely a better bet than ACE which is getting a little long in the tooth.

quixver
  • 564
  • 1
  • 4
  • 11
  • Why Poco isn't better than Boost asio? I didn't try Poco yet, but what it seems to me from documentation, it seems as a much more rounded platform for doing any kind of serious networking than boost. – LavaScornedOven Apr 14 '13 at 22:51
  • Poco is rounded, yet limited. You hardly can extend it, IMO, based on my practice. Regret I can't recall the pack of customization issues leading to abandonment of Poco in my case. – sdd Apr 30 '18 at 19:17
1

If you are allowed to purchase off the shelf library for networking then take a look at JetBytes Server Framework for your networking needs. I remember reading that it did the heavy lifting for the PayPoint. Len Holgate (the man behind the company and the library) is active on these forums to.

graham.reeds
  • 16,230
  • 17
  • 74
  • 137
1

Take a look into www.zeromq.org

It's is not exactly what you asked, but it is something that will definitively solve your problem and speed up your development.

zeromq is a lightweight message queue, with a lot of different transports, and it has bindings for a lot of languages.

It is also used in a lot of trading servers.

Rodrigo Pinho Pereira de Souza
  • 416
  • 7
  • 6
  • 1
    +1 for mentioning 0mq. Although I would not recommend it for a windows environment due to the lack of support for overlapped i/o completion ports. – quixver Feb 19 '13 at 21:04
0

following tasks:

  • handle authentication of clients and provide session id for each session.

If you have SSL from the beginning then you can have server and client auth which would cover this task without having to add additional custom auth to your client/server apps.

Greg Domjan
  • 13,943
  • 6
  • 43
  • 59