Java：在 TCP/IP 消息中包含标签的常用方法是什么

Question

I designed a protocol for sending TCP/IP messages between peers in a peer-to-peer system. A message is a byte array in which the first byte indicates the wanted operation. Then follow the arguments.

To reconstruct the arguments I read byte per byte. Because it is possible that there are multiple arguments I have to put tags in between them (I call it an end of argument byte).

What is the common way for including such tags?

Currently I use 1 byte for representing the end of argument tag (number 17). It is important that I use a/multiple byte(s) that will never be contained in an argument (else it will be interpreted as an end of argument byte).

First I thought to use number 17 as end of argument byte as that is the ASCII value for "device controller 1". But now I'm not 100% sure that it will never be contained in an argument. Arguments are files (any possible file, for example : txt, doc but also for example an image or ...).

Answer 1

You cannot insert separators without making any assumptions about data that will be residing between them. If your protocol is to be generic as possible then it should support byte arrays type which can potentially conflict with your separator bits.

I suggest to take the same way as the typical binary serialization formats out there (eg AVRO), but in your case as you don't have any kind of schema definition, you will need to adjust it a bit to have a type information inside like Thrift or Protobuf do, but without schema.

Try the following format:

[ type1 ][ length1 ][ data ][ type2 ][ length2 ][ data2 ]...[ lengthN ][ dataN ]

Size of type tag can be 4 bits which gives you 16 types to be assigned, you can say type 1 is String , 2 - Image JPG , 3 -> Number long , it depends on your needs.

Length can be one byte which gives you ability to indicate length from 1 - 256 , if you want larger length you can say that if length == 256 then there is a continuation of the sequence and proceed to read the same type until you find length < 256 which will be the last for this type.

Pros of this method is that you always know where is the service bytes and where is the actual data . So rather than indicating the end of the argument you will be indicating the beginning + length.

Later you can include schema tag if you will be able to categorize your messages, this will give you the ability to strip the type information of the messages and leave only the schema id and the length tags which can potentially improve the performance.