🚀 go-pugleaf

On Mon, 08 Jul 2002 22:21:44 -0400, Alan Shiers wrote:

> I'm not familiar with telnet as I never have had an occasion 
> to use it. Perhaps you can explain briefly what line-oriented
> protocol is and line terminators.  What are those?  Could you
> show me some examples?  I'm not familiar with CR-LF.

The protocol you have implemented looks something like this:  A 
message consists of a UTF-8 string (the characters preceded by a 
two-byte length) followed by an integer.  The string specifies the 
program name.  The integer is a command, with 99 meaning SHUTDOWN.

When I say a line oriented protocol, I mean something like this:  
A message consists of a variable length string of characters followed 
by a Carriage Return and a Line Feed (i.e. CR-LF).  The first part of 
the messages is the command, which is a string of non-blank characters.  
If the command has parameters, it is followed by a space and then the 
parameters, with a space between each parameter.

So the shutdown command might look like this:

   shutdown appname<CR><LF>

Note the <CR> and <LF> stand for the ASCII Carriage-Return (hex 0D) and 
Line-Feed (hex 0A) characters.

Now say your application keeps track of users and widgets.  You might 
add a diagnostic "show" command with an argument indicating what to 
show:

   show users<CR><LF>
   show widgets<CR><LF>

Now that you have several commands, you might add a help command that 
takes no arguments:

   help<CR><LF>

Telnet is a terminal emulation program.  You can use it to connect to 
another system (that has a telnet server running) and that generally 
gives you a "console" interface to that system.  If I telnet to a 
Windows system, I can type commands through the telnet interface that 
I could type in a "DOS" window and the output from the commands will 
appear in the telnet window.

A telnet client just opens a socket connection to the other system and 
writes what you type to the socket.  It also reads from the socket and 
displays that in the telnet window.  So instead of using your client 
program to connect to your server, you can use telnet.  You will need 
to tell it which port to use rather than the default telnet port (23), 
but aside from that, telnet will work just fine as the client for a 
server that is written this way.

One advantage of this is that it makes it very easy to debug your 
server.  If you use telnet to connect to it, you will know for sure 
what characters are being sent to the server, since you just type them.

Two protocols that work this way are NNTP and SMTP, which are used for 
news and for mail respectively.  The default port for NNTP is 119 and 
for SMTP it is 25.  NNTP servers generally have a help command, so it 
is somewhat self-documenting.  You can try connecting to the news 
server or to your local mail server to see what I mean.  To connect to 
the borland NNTP server, you would use the command:

   telnet newsgroups.borland.com 119

The format of the commands that you see there is exactly the same as 
those that are being used by your news reader when you use it.

Two things you might note about the responses from the server.  One is 
that command replies always consist of a 3 digit number, a space, 
followed by a descriptive text string.  The number is intended for 
programs to use and the text string is for display to the user.  For 
example, if I type the command "group xxxx", since there is no group by 
that name, it will respond:

   411 no such newsgroup

This means you do not have to know or look up these codes when you 
connect this way.

You might also note that when something more than a simple status reply 
is needed, it writes the response as a series of lines (each terminated 
by CT-LF) followed by a line consisting of a single ".".  If one of the 
response lines begins with a ".", it will throw in an additional ".", 
so a line starting with ".." actually means a single ".".

Obviously, none of the specifics here are required.  You define the 
protocol and as long as your client and server speak the same language, 
they should work.  But this approach is used in several protocols which 
makes it easier to understand, and it works well.

There is a more code to write than your one-shot protocol, but it is 
not too hard to implement.  The Oro NetComponents library has classes 
that do some of the work, although it could do a lot more.  I wrote 
some classes on my last job that handled just about everything that 
NetComponents did not handle -- everything but the actual command 
implementations.  Given those classes, writing a new server and client 
took significantly less additional code than your protocol.

Hmmmm.  That turned out longer than I though it would.  I hope I 
covered the questions.  Let me know if I missed something.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html