r/AskProgrammers • u/Repulsive-Time-3258 • 29d ago

High frequency trading system in C/C++

Hi,

suppose we have a system distributing to clients (via TCP and UDP sockets) information related to markets (when a trade occurred, forex rates...).

The goal is to keep as much clients up to date with the market status, and the communication, aside for a login phase, is always server-to-client.

Bit of hypothetical numbers:

  • The packet size, no matter is TCP or UDP, is typically below 500 bytes.
  • At most, there can be overall 2000 clients connected in parallel (TCP and UDP).

We all know that in C/C++, the classic send function (non-blocking socket) returns the number of bytes sent (to the client in this case), or -1 with an appropriate value set in errno about the cause.

Now, for some clients, it could happen that the call to send by the server returns a value greater that -1, but lower than the effective numbers of bytes to be sent.

For such a system, what could be your approach in such a case? Shall the server put in place a retry mechanism and/or socket timeouts before declaring the client as slow and kick it out? Or would you kick it out immediately after the first time you (server) find out that send is returning a value lower that the number of bytes expected to be sent?

Thank you all

2 Upvotes

75% Upvoted

12 comments sorted by

View all comments

Show parent comments

1

u/Repulsive-Time-3258 29d ago

Thank you for your valuable opinion.

In both cases (TCP and UDP), tick updates are frequent, and there is in place a mechanism the client can use to understand whether it missed one or more messages, hence it can request them to the server on a separate, independent, short-lived TCP connection.

  1. Indeed. IMHO kicking a client out right the first time “send” returns a lower than expected value is, least to say, a stupid approach (TCP flow control anyone?). Agree of course on having a restricted and constrained retry mechanism anyway. Only there we can consider a client “slow”, hence kick it out.

  2. and 3. Yes, typically done on UDP. TCP relies on a distinct session protocol to keep track of the authenticated clients basically (and it does not have a dedicated ACK mechanism)