In the trivial Java client example given
above, we sent a single line of text to the
server, and our client only handled the first line of text returned
-- if there was more than one line, we ignored it. This highlights
some important aspects of the "lines of text"-based application
protocols which we have considered:
Our particular client program should read lines of text until
there are no more available - that's the normal behaviour of a
"finger" client. For some other protocols, eg HTTP, we would read
header lines until we encountered a blank line, then switch to
reading a number of bytes of arbitrary data, specified in the
"Content-length: " header.
When data is expressed in "human-readable" form, as lines of
ASCII text, the receiving system has to do some considerable amount
of work to figure out "what it means". The technical term for this
is parsing. A parser is written to implement a set
of grammar rules which define how the data will be
structured.
Later we will look at application (and other) protocols which take
a different approach, whereby data is always sent in a
highly structured format, making parsing either
not necessary, or much simplified. As we shall see, the tradeoff in
these is to lose the "human-readable" exchange of data which makes
the typical Internet application protocols so conceptually
simple.
[Previous Lecture] [Lecture Index] [Next Lecture]