Home/ Questions/Q 6583653
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T16:26:14+00:00

I’m currently testing a managed c# network library I’ve written and I’ve come up

  • 0

I’m currently testing a managed c# network library I’ve written and I’ve come up against an occasional problem. This problem manifests as a very consistent (always within 30ms) 5000ms block on networkstream.write() for perhaps 1% of all send operations. This is in a test environment, all running locally, using the exact same packet size (2MB) each time. On the client end I continuously write the following to a connected networkstream:

tcpClientNetworkStream.Write(headerBytes, 0, headerBytes.Length);
tcpClientNetworkStream.Write(dataBytes, 0, dataBytes.Length);

and on the server end I use an asynchronous read waiting for data. Once data appears I use a while loop over tcpClientNetworkStream.DataAvailable until all data has been received.

I am aware that networkstream.write() can block if the buffers are full but if this is the problem I can’t think of a quicker way of clearing them at the server end (Send and Receive buffer sizes are default at 8192 bytes). The fact the block is so consistent seems very odd. My first thought was possibly some form of Thread.Sleep but doing a full project search shows none. If anyone could help shed some light on this issue that would be greatly appreciated.

Marc

edit to add: A hack which seems to make the problem go away is the following (although there is an associated performance hit due to the BlockCopy):

byte[] bytesToSend = new byte[headerBytes.Length + dataBytes.Length];
Buffer.BlockCopy(headerBytes, 0, bytesToSend, 0, headerBytes.Length);
Buffer.BlockCopy(dataBytes, 0, bytesToSend, headerBytes.Length, dataBytes.Length);
tcpClientNetworkStream.Write(bytesToSend, 0, bytesToSend.Length);

edit to add2: I’ve also reproduced the problem by using two asynchronous writes with a thread signal between the two. At the moment the only solution I have is the single write operation as in the above edit.

edit to add3: Ok, another possible fix follows. I’m still interested to know why the successive write occasionally ‘blocks’ in the way it does.

BufferedStream sendStream = new BufferedStream(tcpClientNetworkStream);
sendStream.Write(bytesToSend, 0, bytesToSend.Length);
sendStream.Write(packet.PacketData, 0, packet.PacketData.Length);
sendStream.Flush();

edit to add4: After further extensive testing the solution in ‘edit to add3’ does not make the problem go away, it just reduces the occurrence to about 0.1% of sends. Much better but far from solved. I will be replacing the asynchronous read with a blocking read next to see if that sorts it, as suggested by PaulF.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ok, no specific answers to this question so I will do my best to provide a little conclusion myself. My best guess is that this problem was originally caused because I was filling the tcp buffer faster than I was clearing it. If the buffer is filled there is some unknown wait time before attempting to add more data. This problem would perhaps be most apparent when sending and receiving data within the same machine. It’s important to remember that the default read buffer size in .net is only 8192 bytes, so if writing in much larger chunks, perhaps consider increasing this read buffer size to something larger such as 512000 bytes. However this in itself causes other issues due to the large object heap etc but that is potentially discussion to a different question.

    • 0