0

If I am not reading data from socket fast enough, the TCP protocol will decrease sliding windows size and sender might get blocked during sending (as discussed here what happens when I don't manage to call `recv` fast enough?).

How do I detect this situation on receiver side on Windows - preferably directly in C# code and without impacting the performance of reading from socket? Other monitoring solution (perfmon, wireshark) is also acceptable but far less optimal for my scenario.

What is the exact scenario? Let's say the server app can transmit data with speed up to 1Mbps, however my client app is able to receive the data only with the speed of 0.5Mbps. How do I find out in the client application that TCP flow control is kicking in and decreasing the transmit speed?

I came over Socket.Available property http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.available.aspx and was wondering if that might be recomendable way of querying this information?

Community
  • 1
  • 1
Jan
  • 1,905
  • 17
  • 41

2 Answers2

1

You would be better off reading as fast as you possibly can, rather than wasting time trying to have the system tell you you're not reading fast enough, which can only slow down your reading even further. If you're reading at maximum speed and the sender is still getting blocked, TCP is working correctly and there is nothing you can do about it, except maybe look into a faster machine.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • There are many options what to do in order to optimize - optimize the code, optimize the business logic (throw away some messages without further processing) or even - as you mentioned - optimize the hardware. The question is - how to find out that some optimization is even needed? Without the access to server app of course.. – Jan Jun 06 '13 at 09:08
  • @user2308106 I do not understand the point of your comment. My answer seems clear to me. Building in more code to discover that you're reading too slowly is the wrong approach. What are you going to do if the condition trips? Read more quickly. So why not do that all the time? Your question and this comment really don't make much sense. – user207421 Jun 07 '13 at 13:20
  • @user2308106 the point is TCP is meant to handle transmission control so you don't have to. – matt-dot-net Jun 07 '13 at 13:50
  • @EJP I understand your point - from technical point of view it's correct. However time and budged of each project is limited and we need to prioritize before investing into optimization (premature optimization ... - you know this one). Think about this as optimization of memory or CPU usage - you also always measure first before optimizing the code. And there is always way how to optimize (In this particular case we can rewrite third party messaging library we are using - but nobody would approve that cost without hard numbers) – Jan Jun 10 '13 at 09:11
0

The TCP Window is handled by the Kernel and won't be available to you. I guess you could possibly compare the ReceiveBufferSize with number of bytes Received. If this buffer isn't full, then you are waiting.

matt-dot-net
  • 4,204
  • 21
  • 24
  • Best answer so far. Unfortunately I currently wrap the socket into NetworkStream (and that into SslStream) and read from it with BeginRead-EndRead functions; so your solution would require some rearchitecture... So if there would be any other suggestions - I will welcome them. – Jan Jun 07 '13 at 05:47