Hm, how you explain in this case good performance for udp? It was exactly the same amount of clients. Moreover, with udp test, it was the same network configuration. Based on this facts i guess that something wrong with tcp server or tcp client itself. To check this assumption, i suggest just take one of the asio examples, like echo server and test it instead.

yep you right tcp a quite more complex. I don't understand how this affected experimental data represented before. Well, you switch NO_DELAY for the clients, server can utilize this loading without problem (220kb/s according udp tests). What's serious difference? Only ack's sending, that's all. So, if you have not a significant amount of lost packets, the performance of udp and tcp will be comparable (the difference will be tenth but not hundreds pro cents, moreover sometime tcp faster then udp, why? tcp can glues packets before sending...). So, thats conclusion: I see only two reasons this strange degradation tcp: the client and server sockets has not bin configured correctly, and the packet loss. The packet loss can be measure adding counters to udp packet.

Does it make sense? :)

Op, just recall I used to have the similar problem when my cheap switch didn't work correctly. I'd got either ping and udp packets but tcp did work very very slow. After all I just measured how many packets was lost...