0

We have done some basic TCP communication, but have a few questions. We are communicating with a TCP server where the transaction flow is described as follows:

The sender initiates the transaction by sending an STX (ASCII 0x02) character, then waits for the recipient to reply by sending an ACK (ASCII 0x06) character. After an ACK is received, the sender transmits a four-byte, unsigned, big-endian integer representing the size of the message payload, followed by the payload, and finally a 16-byte MD5 message digest for the payload. If the recipient is satisfied with the message, it sends an ACK character.

<STX> = ASCII 0x02
<ACK> = ASCII 0x06

Sender: <STX>     <0x00><0x00><0x00><0x05><'H'><'E'><'L'><'L'><'O'><0xEB><0x61>...
Recipient:   <ACK>                                                                <ACK>

Using .Net sockets (System.Net.Sockets.Socket), what is the proper way to manage the STX/ACK transfer control? Does the socket handle this automatically (i.e. Do we simply call socket.Send(byteData)), or do we need to explicitly send the STX, wait for ACK, etc.?

The same goes for receiving: Do we simply receive the incoming data, or do we need to listen for an STX character, send an ACK, prepare for the payload, etc.?

If the transfer control is handled automatically, are there any specific socket flags that we need to set?

FYI: We found several links (like the following) that have proved useful for message framing, but none discuss the STX/ACK transfer control:

Steven King
  • 562
  • 1
  • 8
  • 13

2 Answers2

2

TCP does not know about your application-level protocol. TCP socket is just a bi-directional byte stream. You have to explicitly send/read those STX and ACK bytes.

Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
2

Hehe, this used to be a serial port protocol, they probably just moved it unchanged to use sockets instead. Not that uncommon, although it isn't very suitable for a stream like TCP implements.

Well, follow the instructions. Assuming you are the client, read one byte and verify its is 0x02. If it is, send back one byte, 0x06. If not, keep reading until you see the 0x02. You're now 'connected', but you already knew that.

Next, read 4 bytes so you know the packet length, read as many bytes + 2 to get the rest of the packet. I'd ignore the 'MD5 digest', TCP is reliable enough to not have to double-check the validity of the received data. Send back one byte, 0x06.

The only thing that isn't clear is whether you should expect a 0x02 before the packet length or not. The text says you don't, the diagram says you do.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • We had implemented this method, sending STX, waiting until we receive ACK, sending length + payload + MD5, waiting until we receive another ACK, then completing the "send". The problem is that it's in a synchronous process. It _shouldn't_ take long for this to complete, but it's possible that we may need to receive similar data while waiting for an ACK. What's the best approach for doing this asynchronously? – Steven King Jan 11 '11 at 20:47
  • I know how to do async sockets, just not the best approach to handle the handshaking asynchronously. Should the receive callback trigger a send based on the data received, or is there a better way to do this? E.g. If ACK is received, send next item in send queue. If STX is received, send ACK. If payload is received, send ACK, etc. – Steven King Jan 12 '11 at 15:06
  • Yes, use a state machine to figure out what to do next. – Hans Passant Jan 12 '11 at 15:14
  • That's what we figured. Thanks. – Steven King Jan 12 '11 at 17:42