12

I have written a simple TCP client and server. The problem lies with the client.

I'm having some trouble reading the entire response from the server. I must let the thread sleep to allow all the data be sent.

I've tried a few times to convert this code into a loop that runs until the server is finished sending data.

// Init & connect to client
TcpClient client = new TcpClient();
Console.WriteLine("Connecting.....");
client.Connect("192.168.1.160", 9988);

// Stream string to server
input += "\n";
Stream stm = client.GetStream();
ASCIIEncoding asen = new ASCIIEncoding();
byte[] ba = asen.GetBytes(input);
stm.Write(ba, 0, ba.Length);

// Read response from server.
byte[] buffer = new byte[1024];

System.Threading.Thread.Sleep(1000); // Huh, why do I need to wait?

int bytesRead = stm.Read(buffer, 0, buffer.Length);
response = Encoding.ASCII.GetString(buffer, 0, bytesRead);
Console.WriteLine("Response String: "+response);

client.Close();
John Saunders
  • 160,644
  • 26
  • 247
  • 397
jim
  • 8,670
  • 15
  • 78
  • 149
  • 4
    The client needs some way to find out when the server is finished (eg, a length prefix for a special termination sequence) – SLaks Nov 06 '11 at 14:29
  • 1
    Try using StreamReader http://msdn.microsoft.com/en-us/library/system.io.streamreader.aspx – David Nov 06 '11 at 14:44
  • 4
    How would StreamReader help? It doesn't know when the server is finished either. – John Saunders Nov 06 '11 at 15:26

4 Answers4

28

The nature of streams that are built on top of sockets is that you have an open pipeline that transmits and receives data until the socket is closed.

However, because of the nature of client/server interactions, this pipeline isn't always guaranteed to have content on it to be read. The client and server have to agree to send content over the pipeline.

When you take the Stream abstraction in .NET and overlay it on the concept of sockets, the requirement for an agreement between the client and server still applies; you can call Stream.Read all you want, but if the socket that your Stream is connected to on the other side isn't sending content, the call will just wait until there is content.

This is why protocols exist. At their most basic level, they help define what a complete message that is sent between two parties is. Usually, the mechanism is something along the lines of:

  • A length-prefixed message where the number of bytes to be read is sent before the message
  • A pattern of characters used to mark the end of a message (this is less common depending on the content that is being sent, the more arbitrary any part of the message can be, the less likely this will be used)

That said you aren't adhering to the above; your call to Stream.Read is just saying "read 1024 bytes" when in reality, there might not be 1024 bytes to be read. If that's the case, the call to Stream.Read will block until that's been populated.

The reason the call to Thread.Sleep probably works is because by the time a second goes by, the Stream has 1024 bytes on it to read and it doesn't block.

Additionally, if you truly want to read 1024 bytes, you can't assume that the call to Stream.Read will populate 1024 bytes of data. The return value for the Stream.Read method tells you how many bytes were actually read. If you need more for your message, then you need to make additional calls to Stream.Read.

Jon Skeet wrote up the exact way to do this if you want a sample.

Rob
  • 110
  • 4
casperOne
  • 73,706
  • 19
  • 184
  • 253
  • 3
    Jon Skeet's article is fantastic, thanks for letting know. +1 – ahmet alp balkan Apr 19 '13 at 17:48
  • Object deserialization provides a solution to the length/end-of-message marker problem. With protobuf for example `.Deserialize(stream)` will automatically read until it has the entire object. Under the hood, protobuf has its own way of determining start/end of objects. This assumes the serialization library implements streams properly. File streams also often return less than the full buffer of bytes(for performance reasons), so any properly written read loop should check actual number of bytes read and not assume the full buffer was filled in a single `.Read`. – AaronLS Jan 20 '15 at 04:21
  • One correction, you should use `DeserializeWithLengthPrefix` and its `SerializeWithLengthPrefix` counterpart as per http://stackoverflow.com/a/8901333/84206 – AaronLS Jan 20 '15 at 05:20
  • 1
    Perhaps things were different when you wrote this answer, but `Stream.Read` will not block until the requested number of bytes are read. The third argument is documented as *"The **maximum** number of bytes to be read from the current stream."* and its return value is documented as *"The total number of bytes read into the buffer. This can be less than the number of bytes requested if that many bytes are not currently available, or zero (0) if the end of the stream has been reached."* – user247702 May 15 '17 at 22:06
2

Try to repeat the

int bytesRead = stm.Read(buffer, 0, buffer.Length);

while bytesRead > 0. It is a common pattern for that as i remember. Of course don't forget to pass appropriate params for buffer.

Grigory
  • 1,911
  • 1
  • 16
  • 29
1

You dont know the size of data you will be reading so you have to set a mechanism to decide. One is timeout and another is using delimiters.

On your example you read whatever data from just one iteration(read) because you dont set the timeout for reading and using default value thats "0" milisecond. So you have to sleep just 1000 ms. You get same effect with using recieve time out to 1000 ms.

I think using lenght of data as prefix is not the real solution because when socket is closed by both sides, socket time-wait situation can not handled properly. Same data can be send to server and cause server to get exception . We used prefix-ending character sequence. After every read we check the data for start and end character sequence, if we cant get end characters, we call another read. But of course this works only if you have the control of server side and client side code.

Ahmet Arslan
  • 5,380
  • 2
  • 33
  • 35
  • do we really need to implement this "start/end character" by ourselves, or does .NET already handles it? – alansiqueira27 Sep 07 '14 at 00:05
  • 1
    "start/end characters" are custom so .net does not implement such things.Actually we impemented a system using lenght of data as message prefix and system is working correctly. But you have to implement robust socket architecture. You can use this code http://stackoverflow.com/questions/869744/how-to-write-a-scalable-tcp-ip-based-server/20147995#20147995 – Ahmet Arslan Sep 09 '14 at 08:04
0

In the TCP Client / Server I just wrote I generate the packet I want to send to a memory stream, then take the length of that stream and use it as a prefix when sending the data. That way the client knows how many bytes of data it's going to need to read for a full packet.

Bradley Uffner
  • 16,641
  • 3
  • 39
  • 76