Re: Use of TELNET for testing protocols

I've dealt with both binary (straight-forward marshalling onto the wire,
nothing baroque like PER) and text protocols, and have not
found a particular advantage to either in terms of debugging. To me,
use of telnet is hardly a compelling argument one way or the other.

Putting a breakpoint on the stubs on either end in a debugger,
and dumping the data structures, has often been easier than having
to scratch my head about syntax being correct (and the generation
and parsing thereof) in a text based protocol.  Not having the same
class of parsing bugs in binary implementations helps muchly on their
side of the equasion.

Note that binary protocols must be well engineered when it comes to
extensions, or they get into trouble in the long term.  There are
similar problems with text protocols: a good example is HTTP, where there
is about 4 different ways to figure out if a message is complete (some
of which require fondling every byte fondly as it goes by).

I find worrying about one or the other pretty close to a religious debate,
not amenable to rational discussion, and only an issue when either:
	o latency requirements force a tight encoding
	o The protocol parameters are a significant fraction of the payload,
	and bandwidth becomes an issue.

So this is/should be an engineering decision, examined in the light of
the application.

And as far as I'm concerned, all this is another argument for modularity
in any protocol stack, so that argument marshalling is one of the modules
that can be traded off on a per application basis.
				- Jim Gettys

Received on Wednesday, 17 February 1999 10:34:54 UTC