CODEWITHSUNDEEP
c#sockets
Kelly Elton
Kelly Elton

Reputation: 4427

c# socket multiple packets stack

I'm having an issue using Sockets in c#. Heres an example. Say I send the number 1, then I immediately send the number 2. The problem I run into sometimes is the client that is supposed to receive it will receive a packet containing '12'. I was wondering if there was a built in way to distinguish packets without using characters or something to separate the data.

To sum it up again, I said two packets. One with the number '1', one with the number '2'. Server receives 1 packet with the data '12'. I don't want to separate the packets with characters, like this ':1::2:' or anything like that, as I don't always have control over the format of the incoming data.

Any ideas?

Like if I do this

client.Send(new byte[1]{'1'}, 1,SocketFlags.None);
client.Send(new byte[1]{'2'}, 1,SocketFlags.None);

then on the server end

byte[] data = new byte[1024];
client.Receive(data);

data sometimes comes back with "12" even though I do two separate sends.

Upvotes: 2

Views: 4707

Answers (4)

Stephen Cleary
Stephen Cleary

Reputation: 456407

TCP/IP works on a stream abstraction, not a packet abstraction.

When you call Send, you are not sending a packet. You are only appending bytes to a stream.

When you call Receive, you are not receiving a packet. You are only receiving bytes from a stream.

So, you must define where a "message" begins and ends. There are only three possible solutions:

  1. Every message has a known size (e.g., all messages are 42 bytes). In this case, you just keep Receiveing the data until you get that many bytes.
  2. Use delimiters, which you're already aware of.
  3. Use length prefixing (e.g., prefix each message with a 4-byte length-of-message). In this case, you keep Receiveing the length prefix until it arrives, decode it to get the actual length of the message, and then keep Receiveing the message itself.

You must do the message framing yourself. TCP/IP cannot do it for you.

Upvotes: 6

aaaa bbbb
aaaa bbbb

Reputation: 3043

You must put into your TCP messages delimiters or use byte counts to tell where one message starts and another begins.

Your code has another serious error. TCP sockets may not give you all the data in a single call to Receive. You must loop on receiving of data until your application-specific records in the data stream indicate the entire message has been received. Your call to client.Receive(data) returns the count of bytes received. You should capture that number.

Likewise, when you send data, all of your data might not be sent in a single call. You must loop on sending of data until the count of bytes sent is equal to what you intended to send. The call to client.Send returns the actual count of bytes sent, which may not be all you tried to send!

The most common error I see people make with sockets is that they don't loop on the Send and Receive. If you understand why you need to do the looping, then you know why you need to have a delimiter or a byte count.

Upvotes: 1

meklarian
meklarian

Reputation: 6625

TCP is a streaming protocol, so you will always receive whatever data has arrived since the last read, up to the streaming window size on the recipient's end. This buffer can be filled with data received from multiple packets of any given size sent by the sender.

TCP Receive Window Size and Scaling @ MSDN

Although you have observed 1 unified blob of data containing 2 bytes on the receiving end in your example, it is possible to receive sequences of 1 byte by 1 byte (as sent by your sender) depending on network conditions, as well as many possible combinations of 0, 1, and 2 byte reads if you are doing non-blocking reads. When debugging on a typical uncongested LAN or a loopback setup, you will almost never see this if there is no delay on the sending side. There are ways, at lower levels of the network stack, to detect per-packet transmission but they're not used in typical TCP programming and are out of application scope.

If you switch to UDP, then every packet will be received as it was sent, which would match your expectations. This may suit you better, but keep in mind that UDP has no delivery promises and network routing may cause packets to be delivered out of order.

You should look into delimiting your data or finding some other method to detect when you have reached the end of a unit of data as defined by your application, and stick with TCP.

Upvotes: 5

Polity
Polity

Reputation: 15130

Its hard to answer your question without knowing the context. In contrast, by default, TCP/IP handles packet management for you automaticly (although you receive it in a streambased fashion). However when you have a very specific (bad?) implementation, you can send multiple streams over 1 socket at the same time making it impossible for lower level TCP/IP to detect the difference. Thereby making it very hard for yourself to identify different streams on the client. The only solution for this would be to send 2 totally unique streams (e.g. stream 1 only sends bytes lower then 127 and stream 2 only sends bytes higher or equal to 127). Yet again, this is terrible behavior

Upvotes: 2

Related Questions