Lecture 24: Data Formats and Encoding

Parsing

ASCII text-based protocols have the advantage of human readability, which has aided the debugging and development of these protocols. Also, many other data types can easily expressed in ASCII -- for example, numeric data: eg, the ASCII string "2529" is clearly an integer. Note, however, that even such a simple system has potential pitfalls: think of the textfile conventions of Unix systems, PCs and Macs vis-a-vis the telnet NVT "line-of-text" convention used in these protocols.

Protocol messages in these classic Internet application are structured to conform to a grammar -- a set of syntax rules. The receiver of such a message has to parse it to discover its meaning. This can be compared to the process whereby (eg) a Java source file is compiled to a byte-code equivalent. The problem here is that writing a parser is (still) considered to be a difficult programming problem, and developers tend to try and avoid them if possible...

In contrast, an ASN.1/BER bytestream can be interpreted using (in principle, at least) a somewhat simpler pattern matcher. Such software is, in general, easier to write -- it can be written using a "Finite State Machine" model, or could even be as simple as a sequence of nested IF-statements. The downside is a protocol that can't be tested using "human-readable" messages. TANSTAAFL.

Lecture 24: Data Formats and Encoding -- A Philosophy Lecture

previous | start | next