re: Telnet line or record limit?

Mark Crispin <> Thu, 21 April 1994 18:22 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa16791; 21 Apr 94 14:22 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16787; 21 Apr 94 14:22 EDT
Received: from by CNRI.Reston.VA.US id aa14349; 21 Apr 94 14:22 EDT
Received: from ( by (Bob mailer 1.2) id AA05210; Thu, 21 Apr 94 13:12:10 CDT
Received: by (5.0/CRI-5.14 Sdiv) id AA04399; Thu, 21 Apr 1994 13:12:05 +0600
Received: from ( by (5.0/CRI-5.14 Sdiv) id AA04389; Thu, 21 Apr 1994 13:12:01 +0600
Received: from Tomobiki-Cho.CAC.Washington.EDU by (Bob mailer 1.2) id AA05176; Thu, 21 Apr 94 13:11:57 CDT
Received: from Ikkoku-Kan.Panda.COM by Tomobiki-Cho.CAC.Washington.EDU (NX5.67e/UW-NDC Revision: 2.27.MRC ) id AA28607; Thu, 21 Apr 94 11:11:48 -0700
Received: from localhost by Ikkoku-Kan.Panda.COM (NX5.67e/UW-NDC/Panda Revision: 2.27.MRC ) id AA01935; Thu, 21 Apr 94 11:11:39 -0700
Date: Thu, 21 Apr 1994 10:55:39 -0700 (PDT)
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mark Crispin <>
X-Orig-Sender: Mark Crispin <>
Subject: re: Telnet line or record limit?
To: Tom Schlender <>
In-Reply-To: <>
Message-Id: <MailManager.766950939.258.mrc@Ikkoku-Kan.Panda.COM>
Mime-Version: 1.0
Content-Length: 2251

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.