What exactly are the pros and cons of using a plain-text protocol over binary, or vice-versa?

Well, The major one that I can think of, is that it is harder to crack a binary(w/e you want to call it) protocall, then it is a plain-text one.

Also the fact that you can use Bytes to represent numbers, so you can use the byte 0xFF to represent 255. With in hex I beleave would be 32 35 35, Or w/e witch is three times as long. So it saves some space.

I beleace it is easier to use bytes representing diffrent packets then it is to have text representing diffrent packets.
0xFF insted of "[UserTalk]"
~-~(HDX)~-~

I had a conversation about this with iago a while back...

http://www.madzlair.net/madzb/forums/index.php?topic=49.0

Basically, it all comes down to speed vs. portability.

[quote author=LoRd[nK] link=topic=10805.msg102489#msg102489 date=1109978310]
Basically, it all comes down to speed vs. portability.
[/quote]
Yes, the few milliseconds slower the text-based protocol is makes one hell of a difference. =P

For portability, text-based is better
For ease of debugging, text-based is better
For teaching people how to use it, text-based is better

If you require complexity with more information stored, you may neither either a binary protocol or xml.  I would recommend xml for the reasons above.

Binary's actually quite portable; the only thing to watch for is people who try to use the wrong endianness.  Text protocols are also more of a nuisance to write parsers for, whereas a binary protocol can often be handled with just a few jump tables.  Also, text-based protocols are inherently more bloated, which can become a nuisance if you're exchanging enough traffic that you actually start hitting your bandwidth limit.  (Think about why people started discussing "binary XML"!)

Ease of "cracking" a protocol really doesn't depend all that much on text vs. binary.  For instance, consider the BNCS chatgate protocol.  Without the extra junk field of "USER", "JOIN", "LEAVE", etc., it'd be about as resistant to attack as the bnbinary protocol, since both are just exchanges of numbers with user chosen strings thrown in.  The bnbinary protocol is of course more compact for the amount of information it passes.

[quote author=Kp link=topic=10805.msg102501#msg102501 date=1109981406]The bnbinary protocol is of course more compact for the amount of information it passes.[/quote]Which of course would save a bundle on Battle.net's bandwidth costs.

Think of it this way. You're sending a 100 megabyte file as binary. Now change all those bytes into numeric strings. Your file has now jumped in size by two to three times. That's double to triple the amount of time it takes to transfer the file. That's double to triple the amount of bandwidth use.

The only real advantage that text-based protocols provide over binary-based protocols is that it's a crapload easier to read them on-the-fly. No special parsers are needed. Binary protocols are smaller, faster, and usually a lot easier to handle (eg, write code for) in most good languages with competent programmers (eg, "how do i get the integer into the string" wouldn't be competent).

I would choose a binary protocol over a text protocol any day.

[quote author=tA-Kane link=topic=10805.msg102530#msg102530 date=1109993235]
Think of it this way. You're sending a 100 megabyte file as binary. Now change all those bytes into numeric strings. Your file has now jumped in size by two to three times. That's double to triple the amount of time it takes to transfer the file. That's double to triple the amount of bandwidth use.
[/quote]
Interestingly enough, that's true except for users on a modem connection, where binary compression has more effectiveness on text data than binary data.  :P

At least, as far as I can tell.  :P

[quote author=MyndFyre link=topic=10805.msg102534#msg102534 date=1109996964]
Interestingly enough, that's true except for users on a modem connection, where binary compression has more effectiveness on text data than binary data.  :P

At least, as far as I can tell.  :P
[/quote]

I don't think you've experimented enough then. The size increase by far outweighs the compression improvement :)


[quote author=iago link=topic=10805.msg102495#msg102495 date=1109980646]
For portability, text-based is better
For ease of debugging, text-based is better
For teaching people how to use it, text-based is better
[/quote]

For portability, text-based becomes a pain as soon as you involve \r\n vs \n, different decimal separators (,.), different thousand separators (  ), different date formats (##/##/##, ####-##-##), etc. Just consider parsing and generating all the various Date headers you can find in a mail, and compare that to if they'd just sent a simple time_t....

For ease of debugging, debugging a parser for a text protocol can get much more of a pain than debugging a binary protocol depending on what kind of bugs you're having. A binary protocol with easily separatable top-level packets (say length-prefixed) shouldn't be any more difficult to debug than a text based one.

Teaching people to use it may be easier though, especially teaching them to use it through telnet :)

So far the only real advantage I see of using a binary over text-based is the fact that it requires a few bytes less of data, perhaps text-based was a strain back when 56k was the standard, but with DSL and Cable around I don't see how it is that binary would be better for a small-ish server

[quote author=Ban link=topic=10805.msg102611#msg102611 date=1110065516]
So far the only real advantage I see of using a binary over text-based is the fact that it requires a few bytes less of data, perhaps text-based was a strain back when 56k was the standard, but with DSL and Cable around I don't see how it is that binary would be better for a small-ish server
[/quote]

Have you actually read all the responses in this thread?  We explain that there're advantages to binary protocols, such as simpler design of parsers and less bandwidth usage.  I'm getting rather tired of dealing with people who use the argument that "it doesn't matter because the hardware can handle the inefficient approach"; also, remember that many people are not yet on broadband connections.

[quote author=Kp link=topic=10805.msg102620#msg102620 date=1110071383]
[quote author=Ban link=topic=10805.msg102611#msg102611 date=1110065516]
So far the only real advantage I see of using a binary over text-based is the fact that it requires a few bytes less of data, perhaps text-based was a strain back when 56k was the standard, but with DSL and Cable around I don't see how it is that binary would be better for a small-ish server
[/quote]

Have you actually read all the responses in this thread? We explain that there're advantages to binary protocols, such as simpler design of parsers and less bandwidth usage. I'm getting rather tired of dealing with people who use the argument that "it doesn't matter because the hardware can handle the inefficient approach"; also, remember that many people are not yet on broadband connections.
[/quote]

Yes, I have read all the responses Kp, and that is the conclusion have I have drawn. a text-based protocol is easier to implement and understand, and if your worried about security there are easy ways to fix that (encryption w/ session key, hashing, whole differn't topic). I don't see how binary has any major advantage over text-based protocols unless your talking about filetransfers or extremely high bandwith usage situations.

There are some other common weaknesses to text based protocols. If you want to transfer user-input data in a text-based protocol, you need to use some kind of escape sequences. The parsing of those escape sequences easily get much more complex than if you had chosen a binary protocol from the start. If you make a mistake and the user can generate an escape sequence, you're in for evil debugging or exploits.

Is it really that much harder to make a parser? You could probably make a simple parser in 5 minutes.

To whoever said that bandwidth is a factor: text compresses very well, so use a text protocol and compress it.  Compare the file size of MS Word documents (binary files) to equivilant OpenOffice files (gzipped xml), and you'll see a big difference. 

To whoever said that things like dates/escape sequences need to be standardized: xml.

[quote author=iago link=topic=10805.msg102652#msg102652 date=1110085784]
To whoever said that bandwidth is a factor: text compresses very well, so use a text protocol and compress it.  Compare the file size of MS Word documents (binary files) to equivilant OpenOffice files (gzipped xml), and you'll see a big difference. 

To whoever said that things like dates/escape sequences need to be standardized: xml.
[/quote]

Haha, and try writing an XML parser... Luckily there are libraries available for a few languages, but XML really isn't as simple a solution as a binary protocol would be.

The reason MS Word documents get so large is that they contain a lot of information apart from the document text itself. And, they do zip pretty well. Generally, binary storage containing the same information as an XML version will always compress better.

[quote author=iago link=topic=10805.msg102652#msg102652 date=1110085784]
To whoever said that bandwidth is a factor: text compresses very well, so use a text protocol and compress it.  Compare the file size of MS Word documents (binary files) to equivilant OpenOffice files (gzipped xml), and you'll see a big difference. 
[/quote]
I'm not entirely sure what is included inside of a Word file, but given that a completely empty Word document is roughly 20kb, I would have to say that there's a problem with that argument somehow.  Plus as Adron pointed out, you can zip a Word document; you're comparing an uncompressed file to a compressed file otherwise.  I believe all the stuff inside a Word document is there to enhance backward-compatibility; note that you can probably open a Word 2003 file in Word 97 with maybe a few bugs.  But if you try to validate an XML file against a strict DOM, a good parser (*ahem*, an accurate parser) will toss you errors.