Binary and text protocols

Question

I am wondering what are the differences between binary and text protocols. I read that binary protocols are more compact / faster to process. How it works? So how should you send the same amount of data? No?

For example, how will the string "hi" differ in size in binary format?

Answer 1

If all you do is transmit the text, then yes, the difference between the two is not very significant. But think about trying to convey things like:

• Numbers. Do you use a string representation of a number or binary? Especially for large numbers, the binary will be more compact.
• Data structures. How do you indicate the beginning and end of a field in a text log? Sometimes a binary protocol with fixed-length fields is more compact.

Answer 2

Text protocols are better in terms of readability, ease of redefinition, and ease of debugging. Binary protocols are more compact.

However, you can compress your text using the LZO or Zlib library, and it is almost as compact as binary (with a very low performance value for compression / decompression).

You can read more information on this subject here:
http://www.faqs.org/docs/artu/ch05s01.html

Answer 3

The string "hello" by itself will not vary in size. The difference in size / performance is the additional information that serialization introduces (Serialization is how the program presents the transmitted data so that it can be rebuilt after it gets to the other end of the pipe).

For example, when serializing in .NET using XML (one of the methods for serializing text):

string helloWorld = "Hello World!"; 

You can get something like (I know it is not):

 <helloWorld type="String">Hello World!</helloWorld> 

While binary serialization could represent this data in binary form without additional markup.

Answer 4

binary protocols are better if you use control bits / bytes

i.e. instead of sending msg: Hello in binary, it could be 0x01 followed by your message (if 0x01 is the control byte that msg stands for)

So, since in the text protocol you send msg: hello \ 0 ... it includes 10 bytes where, as in the binary protocol, it would be 0x01Hello \ 0 ... this includes 7 bytes

And another example, suppose you want to send the number say 255, in the text its 3 bytes where, as in binary, its 1 byte, i.e. 0xFF

Answer 5

If you use ASN.1 and BER to send hello in a protocol message, for example:

 ProtocolMessage ::= String ; 

then 1 byte takes octer to encode its identifier, 1 byte takes for encoding the length, and UTF-8 encoding "hello" - another 5 bytes. Thus, the result message is 7 bytes.

Answer 6

You need to clearly understand what is part of the protocol and what is part of the data. Text protocols can send binary data, and binary protocols can send text data.

The protocol is part of the status message "Hello, can I connect? I have some data, where should I put it?", You have an answer for me: "Thank you, thank you!"

Each conversion bit is (possibly) much less in a binary protocol, such as HTTP (which is text based):

If you had a coding standard, I would say that you could make up a sequence of characters less than 4 bytes needed for the word "PUSH"

Answer 7

I would not say that binary formats are processed faster. If you look at the text format CSV or text format with a fixed field - it can still be quickly processed.

I would say it all depends on who the consumer is. If the person is at the end (for example, for HTTP or RSS), then there is no need to compress the data in any way, with the possible exception of compression.

Binary protocols require parsers / converters; they are difficult to extend and maintain backward compatibility. The higher you use the protocol stack, the more human-centered the protocols are (TCP is binary, because packets must be processed by routers at high speed, but XML is more user-friendly).

I think size variations today are not a big deal. For your example, hello will accept the same amount in binary format as in text format, since the text format is also “binary” for the computer - just the way we interpret the data.