I'm composing communication lyrics for client-server and what am I thinking about:
why I always need to do something like
I can see some secure reasons but I think it's not the real reason so why I can't use strings in client-server communication?
I would advocate a binary protocol based off something like Protocol Buffers. There's little benefit, in my opinion, in a human-readable protocol assuming the protocol isn't meant to be read by a human.
Using protocol buffers gives you the compactness of a binary protocol with the flexibility of a text-based protocol (e.g. with optional fields and the like). It also has the added benefit of being able to generate the serialization/deserialization code for you automatically, so you can use strong-typed objects in your program code.
you CAN use strings (look at the http, ftp, ... protocol) but then you'll likely bump into encoding problems (less now that the UTF8 has become the de facto standard but you'll still bump into stuff like UTF16 and will need to account for that)
you would also need to write a string parser that handles malformed input correctly (if only to drop the connection instead of crashing)
however parsing binary often comes down to a sequence of switch(in&MASK){case FIRST_CASE:...} which is much more efficient
however next to all these is the amount of data you are transmitting: binary can be much more compact than strings for comparable protocol
There are actually very few good reasons to go binary. The one you mentioned -- security -- is a false promise. You are either encrypting your data or not; binary transmission in the clear is still in the clear it just requires a modicum more skill to read. Another reason mentioned -- text encoding -- is effectively a solved problem at this point. On the flip side, binary encoding can create interesting problems -- think big- versus little-endian.
The advantages of text-based protocols are that they are vastly easier to understand, build, debug, use and hack. You don't need nearly as much tooling to get anywhere. When you do need tooling there is an endless array of text-based tools at your disposal. With your custom binary protocol you get to define the toolset for better of for worse.
This is not to say that binary protocols don't have their place -- there are lots of applications that require that sort of compactness and pointedness. But binary should not be the default answer.
Do you need to maintain readability of the protocol itself? If so, why? Human-readable(that is, text strings) protocols like the example you gave have multiple downsides. First obvious one is the bandwidth requirements; it is surely much more compact to send out 0x01, 0x00 than something like "USER LOGIN\n", let alone longer phrases as you described. The second is security. For example what do the bytes 0x3C, 0x02 and 0x7F mean in terms of protocol? The only way to figure out is to start reverse-engineering the binaries. Much more tedious work, and not always that trivial.
Frankly, I see absolutely no real benefits of using human readable protocols, unless they are specifically meant to be human readable - something which I don't see happening that often. I would strongy advice against strings in protocols. Please, don't.
The Internet has lots of experience with binary and textual protocols. Textual protocols are the norm, not because "we always do it that way", but because over 40 years experience has shown that textual protocols are significantly easier to work with, and because bandwidth considerations rarely pan out in the long run.
Don't conflate "binary" and "secure". There's nothing inherently secure about a binary protocol. Even undocumented binary protocols have been reverse-engineered. Similarly, there's nothing inherently insecure about a textual protocol. Security arises from well-thought-out plans against attacks, not from simple obscurity.
There are two reasons that spring to mind:
Encoded requests and responses are usually shorter than "plain text" requests. If you are sending a lot of data this could become important. It's less so these days with faster connections and if you are only sending relatively small amounts of data.
Security is a real concern. If requests and responses are sent in the clear they can be read while in transit (man in the middle attacks) and, given enough packets, your application could be compromised. People could send fake requests to get data out of your system, insert fake data into your system and generally make a mess of things. While this is also true for binary data, it's harder and less obvious what the data is.
