Using simple specific TCP client-server written in Win32 sockets.Request and answer block sizes are small. I am concerned about possible performance problems caused by TCP ping (time of packet arrival). Sending 500 packets of 8 bytes would be slower than sending 1 packet of 4000 bytes because of latency on servers on the route.Amounts in send() and recv() do not affect packet size,as I understand.Is it possible to control the process in any way?
0
votes
if you want more control, ditch TCP
- Red Alert
Can you be more specific about what kind of control you are looking for?
- Jeremy Friesner
Identification of <something>. Send CRC/MD5 - get status of it.Could be 100 items in 0.01 sec and desirable answer ASAP.Send one request and wait for response for it is most convenient ,but could be not satisfactory in speed.
- user3874158
Pipelining will definitely make things go faster, so if the protocol you are using allows it, send all 100 items as quickly as possible, and read back the results as they come in.
- Jeremy Friesner
2 Answers
1
votes
Microsoft has a KB article how to tune the performance of sending small segments over TCP/IP. Check the article to fine tune the TCP/IP to your need: http://support.microsoft.com/kb/214397
0
votes
I am concerned about possible performance problems caused by TCP ping (time of packet arrival).
There's no such thing as 'TCP ping', and if there was it wouldn't have anything to do with 'time of packet arrival'.
Sending 500 packets of 8 bytes would be slower than sending 1 packet of 4000 bytes because of latency on servers on the route.
Probably not. More likely the data would get coalesced partially or completely by the Nagle algorithm.
Amounts in send() and recv() do not affect packet size, as I understand.
Correct, see above.
Is it possible to control the process in any way?
You can turn the Nagle algorithm off, but you haven't established any case for doing so yet.
