re: Telnet line or record limit?

[Mark Crispin <[e-mail]>]

On Thu, 21 Apr 1994 12:49:58 CST, Tom Schlender wrote:
> We recently ran into a situation where a misbehaving Telnet client was
> streaming input to the server.  The server was buffering up the
> input, waiting for the carriage return/line feed.  This caused many
> of its buffers to be consumed.

This sounds like a bug in your Telnet server.  Even a ``misbehaving'' Telnet
client should not be able to consume server resources like that.  Also, what
you refer to as a ``misbehaving'' client may be referred to by others as ``a
perfectly normal client doing an upload.''

> Is there a limit to the size of a Telnet line or record?

No.  The only limits are in the underlying window sizes provided by TCP flow
control.  However, relying upon those limits for your particular application
seems ill-advised, since the result of filling up the TCP window is to block
the TCP stream.  If you never drain the stream, the result is a deadlock.

Although the Telnet specification pays lip service to lines and records, it
really is an character-at-a-time octet stream.  Some functions which purported
to handle record-based activity,, such as the GA that unlocked the keyboard on
an IBM 2741, have been deprecated; others are concerned primarily with
efficient echoing and limited line buffering (and in any case only work with
cooperating clients -- it is not mandatory to implement these functions).

> If there is not
> a limit, how do other Telnet implementations handle this case?
> Any ideas?

On most systems, terminal input is character-at-a-time so this is not an
issue.  Any line buffering is handled by the application; and in the case of
some applications there is no meaningful concept of a ``line'' or ``record''.

I understand that this may be difficult to implement or work around on a
system which thinks in terms of lines or records.  But, at the very least, you
need to defend against adverse consequences that may be caused by the octet
stream nature of Telnet.

My suggestion is to send the data from the server to the application on the
server without regard to newline whenever some internal limit is popped.
Presumably, the application sees newlines, so if it gets a chunk of data
without a newline it will know that more is coming.