Tcp Transport cpu usage

[fedjabosnic]

At present, we have a very simple socket read loop which spins over Socket.DataAvailable. While this is good in terms of reading messages as soon as they arrive, it isn't so good for cpu usage, especially on lower throughput connections where we just chew up cpu needlessly.

Some ideas:

1. Use async mechanisms to read off the socket (perhaps related to issue #4 "Async IO and completion ports")
2. Add an option to enforce some intermittent sleeps within the read loop when no data is available, to give the cpu a rest
3. Switch to a blocking read when no data is available for a predetermined amount of time or spins

[fedjabosnic]

Although this doesn't completely resolve this issue, we have added TCP Afterburn in feature #57.

Afterburn keeps the tcp transport actively polling the socket for a short time after a message is received, in the expectation that the next message will arrive shortly after. If no messages are received within the afterburn period, the tcp transport will fall into a non cpu-bound wait state, awaiting more data on the socket.

• Afterburn mode has lower latency but is extremely cpu bound.
• Normal mode has higher latency but is not cpu bound.

The table below shows the trade-offs between afterburn and normal modes:

Mode	Latency	CPU utilization
Afterburn	Low	High
Normal	High	Low

The afterburn period is currently not configurable (hard-coded to one second), but we will expose this in an upcoming release...