Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!deimos.cis.ksu.edu!unmvax!indri!polyslo!usc!orion.cf.uci.edu!uci-ics!milne
From: milne@ics.uci.edu (Alastair Milne)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  TELNET Buffering Woes
Keywords: telnet delays pc-nfs
Message-ID: <14792@paris.ics.uci.edu>
Date: 17 May 89 03:57:47 GMT
References: <8905021526.AA03195@oliver.cray.com>
Sender: news@paris.ics.uci.edu
Reply-To: Alastair Milne <milne@ics.uci.edu>
Distribution: na
Organization: Educational Technology Center, Dept. of ICS, UC Irvine
Lines: 30

dab@opus.cray.com (Dave Borman) writes
>The problem here is not with the remote machine, but with the local
>telnet implementation.  The way that things should work is:
>	User types ^C
>	Local telnet translates that to, and sends, IAC IP,
>		and then sends IAC DO TIMING-MARK and begins to
>		flush all output.
>	Local telnet receives IAC WILL/WONT TIMING-MARK, and
>		resumes terminal output.
>
>The problem is that many telnet implementations are very dumb.  They
>are not doing local recognition of the interrupt character, and thus
>they don't know when to send the DO TIMING-MARK and start output flushing.

    Sorry if this has already been covered, but: Does anybody know if Sun's
    version of telnet for PC-NFS 3.0 on the IBM PC/PS-2 has such problems?
    While I haven't tried breaking a long unwanted stream with ^C (haven't had
    to yet, fortunately) this telnet is often subject to sudden delays of from
    1 to maybe 8 seconds, during which there is no activity at all, and then a
    rush to catch up.  In our whole department, we seem to be the only ones
    suffering this delay, and I think we're the only ones using PC-NFS.

    Any insights or prior experience with this problem would be welcome.


    Thanks,
    Alastair Milne,
    Educational Technology Center,
    Dept of ICS
    UCalif. Irvine