Re: Use of TELNET for testing protocols

> From: Michael Mealling <michael@bailey.dscga.com>
> Date: Wed, 17 Feb 1999 10:43:39 -0500 (EST)
> To: jg@pa.dec.com (Jim Gettys)
> Cc: joshco@microsoft.com, jpalme@dsv.su.se, discuss@apps.ietf.org
> Subject: Re: Use of TELNET for testing protocols
> -----
> Jim Gettys said this:
> > 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.
> 
> Just a minor nit, your observation is probably correct when you are
> actually writing an implementation of the protocol from scratch. I think
> when most of us speak about 'debugging' a server by simply telnetting
> to the port is after its been built and we are debugging particular
> applications that are using that protocol. Or also in the case where
> we do not have debugging access to the server or client (proprietary
> binaries).
> 
> Also, from a past sysadmin's point of view, you're never gauranteed to
> have the libraries needed to parse a binary protocol on any given client.
> Telnet is everywhere....
> 
> -MM
> 
> Sorry, hard to resist when your particular religion gets tweaked... ;-)

As I said; religious argument...

Then again, I've been involved in several binary protocols, one of which 
has had literally thousands of applications written for it (the X Window 
System protocol).

On the systems that support it, the client libraries are either there
from the vendor, or can be built from source (your preference).

Another debugging tool useful at times for X has been a pseudo-server, 
which dumps the protocol traffic in both directions; this is particularly
useful when looking at performance issues.  This has also allowed looking
at both client and server as black boxes, without poking inside, and
eases finger pointing in binary only situations.

Text protocols and telnet debugging have a lower entry cost, but much 
higher curve as things get compicated.  Binary protocols tend to have 
higher up-front costs (building a bit more infrastructure up front), but 
lower difficultly curves, as the complexity of the protocol goes up.

I stand by my opinion that it is six of one, half a dozen of the other;
what is most appropriate depends on your application.  One size does not
fit all needs.
				- Jim

Received on Wednesday, 17 February 1999 11:57:24 UTC