For some applications, text based protocols aren't very well suited,for instance because of space constraints. Protocols that presentdata such as integer values etc as binary values are usually much morecompact and can be processed much more efficiently than protocols thatrepresent all data as ASCII strings no matter what the underlying datatype is.
There isn't reallythe method of devising binaryrepresentation protocols; there are just a few techniques you'll encounterquite often.
For instance, it is very common to represent integer values as two'scomplement numbers using big-endian byte order (i.e. the most significantbyte first).7.3 It is quite important for a network protocol to define things likethis, otherwise machines with different sizes for integers, or with adifferent byte order, will not be able to talk to one another. Thus,no matter how your machine represents integers natively, it has toconvert them to thecanonical ornetwork representationdefined by the protocol before it can send them. Likewise, when itreceives data from the network, it has to convert it from the canonicalrepresentation to its native one. The same is true for all other datatypes; be it strings, floating point numbers or complex types suchas linked lists of structs (of course, not all protocols try to do thingssuch as sending linked lists across the network, but some do!). Theprocess of converting data objects to the network representation isfrequently calledserialization because potentially complex datastructures are converted to a sequence of bytes. The reverse operation(converting from network representation to host presentation) is calleddeserialization.
As you might expect, encoding complex data types means quite a bit ofcode complexity during serialization and deserialization. And of course,there's a potential for security bugs.
