most efficient winsock design for high load network application

Question

Hello,

I know it is a general question but I need your recommodations about a TCP server/client application.

The server is only supposed to handle one connection at a time. Server is sending live images (one frame is approx. 50K and 20 frames per second) to connected client.

Actually at the startup of the server and client applications connection is established and this connection is supposed to be keep alive forever,in theory.

My point is that since server is sending live images, delay must be minimum, so what is best practice for writing such a (simple) tcp server and client, and how to serialize/deserialize images so that "minumum delay" aim is achieved?

Thanks in advance,

Regards

Answer 1

One way is to send the data using UDP instead of TCP.

If you do, it's possible that some of the UDP packets will be lost (dropped by the network), so your code will need a method (e.g. sequence number in the packet headers) to detect lost packets.

If a TCP packet is lost, then TCP will retransmit it, which results in a delay. It's possible that for your application, when a packet is lost you might just want to do without that lost packet, not retransmit it, don't display this video frame (or display only the partial frame), and go on to display the next frame.

It depends on the application:

• Are you streaming canned/prerecorded/non-real-time video, where you want to receive/display every frame even if some of them cause a delay?

• Are you streaming live video, where you want to display the current frame in near-real-time (and even if some previous frames were lost, you don't want to delay while they're retransmitted)?

---

In terms of winsock architecture, the TransmitFile or TransmitPackets APIs are quite efficient: they're executing in the kernel, instead of causing round trips between your user mode code and O/S kernel mode code as each buffer is transmitted.

---

"minumum delay" aim is achieved

You may want some delay, to avoid jitter: better to have a small (e.g. 150 msec) fixed delay, than a delay which varies from 2 to 120 msec. See http://www.google.ca/search?hl=en&q=jitter+network

Answer 2

I'm not super-authoritative, but...

Let's do some math. 50K per image (that's bytes, right?) at 20 frames per second is about 1 megabyte per second. In communications terms, that's 10 megabits per second. That's a fair-ish bit, but very do-able. Be sure you've got 100 megabit equipment throughout.

The fastest APIs for this are the boring old blocking "send" and "recv" calls (*1). There are other calls which do the Windows IO type completion ports and whatnot; don't use them for this application (because (a) they are overkill and (b) they make an app be more scalable)

Consider turning off the Nagle (the NODELAY option).

(*1) probably. The actual literature on the actual fastest Winsock calls is severely lacking.