TCP listener disconnects message at 1024 bytes

Question

The problem is just starting from the client side. Here is my code where I get a TCP / IP message. On my local PC, this listener gets many K problems without any problems. I tried to increase the size of the buffer, but they still report problems with it on the client site. Only the first 1K (1024 bytes) is still received

public void Start() { //Define TCP listener tcpListener = new TcpListener(IPAddress.Any, IDLocal.LocalSession.PortNumber); try { //Starting TCP listenere tcpListener.Start(); while (true) { var clientSocket = tcpListener.AcceptSocket(); if (clientSocket.Connected) { var netStream = new NetworkStream(clientSocket); // Check to see if this NetworkStream is readable. if (netStream.CanRead) { var myReadBuffer = new byte[1024]; var myCompleteMessage = new StringBuilder(); // Incoming message may be larger than the buffer size. do { var numberOfBytesRead = netStream.Read(myReadBuffer, 0, myReadBuffer.Length); myCompleteMessage.AppendFormat("{0}", Encoding.ASCII.GetString(myReadBuffer, 0, numberOfBytesRead)); } while (netStream.DataAvailable); //All we do is response with "OK" message var sendBytes = Encoding.ASCII.GetBytes("OK"); netStream.Write(sendBytes, 0, sendBytes.Length); clientSocket.Close(); netStream.Dispose(); // Raise event with message we received DataReceived(myCompleteMessage.ToString()); } } } } catch (Exception e) { //If we catch network related exception - send event up IDListenerException(e.Message); } } 

Answer 1

I don't see any problems with the code you sent to extract the message to a string, so I assume something else is happening.

TCP is not required to send all the data you queue at a time. This means that he can send as much as he wants at a time, and he can choose to split your data into pieces at his discretion. In particular, it guarantees the ability to split your data if it does not fit into one package. Typically, the maximum packet size (aka MTU) is 1532 bytes of IIRC.

Therefore, there is a real possibility of sending data, but as several packets. The delay between receiving the first and second packets may mean that when the first arrives to your code, it happily reads everything that it contains, and then stops (no more data) before the second packet arrives.

You can test this hypothesis by observing network traffic or by letting your application pull more messages from Explorer and see if they finally receive all the data you sent (albeit to pieces).

Ultimately, the main problem is the TCP-based (thread-based) thread-based (rather than message-based) principle. even if you execute this code correctly, there is no guarantee that it will continue to work in the future , because it makes assumptions that TCP does not guarantee.

To be safe, you will need to include a message-based structure (for example, adding each piece of data with exactly 4 bytes that occupy its length, and then you can just keep reading forever until you get so many bytes).