Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 (Tek) 9/28/84 based on 9/17/84; site hammer.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!tektronix!orca!hammer!steveh
From: steveh@hammer.UUCP (Stephen Hemminger)
Newsgroups: net.unix-wizards,net.lan,net.bugs.4bsd
Subject: Re: Serious telnetd/rlogin/telnet performance bug
Message-ID: <1957@hammer.UUCP>
Date: Fri, 18-Apr-86 13:12:34 EST
Article-I.D.: hammer.1957
Posted: Fri Apr 18 13:12:34 1986
Date-Received: Sun, 20-Apr-86 16:56:44 EST
References: <380@quest.UUCP>
Reply-To: steveh@hammer.UUCP (Stephen Hemminger)
Distribution: net
Organization: Tektronix, Wilsonville OR
Lines: 43
Xref: watmath net.unix-wizards:17696 net.lan:1432 net.bugs.4bsd:2062

In article <380@quest.UUCP> stuart@quest.UUCP (Stuart Levy ) writes:
>
>I think the main problem with telnetd is not inefficiencies
>in the kernel interface, pty code, and so on.
>Any telnetd which uses select() and non-blocking I/O, as 4.2 and presumably
>4.1c telnetd do, faces a serious performance problem.
>So also do rlogin and user telnet on at least 4.2.
>So, for that matter, will any program which uses select() to determine
>when to attempt non-blocking write()'s.
>
>The REAL way to fix this problem would be to redefine non-blocking
>I/O, I think, to make it possible to indicate a partial read or write
>accompanied by an error, such as EWOULDBLOCK or EINTR.
>Then the problematic case of a terminal read interrupted by a signal,
>where some data had already been transferred, and of this non-blocking
>write where some but not all data could be transferred,
>could be handled neatly.

If you make the simple change (done from 4.2 to 4.3) all these problems
go away.

In <sys/socketvar.h>
Wrong (4.2)
-------
/* do we have to send all at once on a socket? */
#define	sosendallatonce(so) \
    (((so)->so_state & SS_NBIO) || ((so)->so_proto->pr_flags & PR_ATOMIC))
-------
Correct (4.3)
-------
/* do we have to send all at once on a socket? */
#define	sosendallatonce(so) \
    ((so)->so_proto->pr_flags & PR_ATOMIC)
------


Fix this and rebuild your kernel and this problem goes away.

write on a non-blocking socket will do a partial write (unless it is atomic)
-- 
  Stephen Hemminger		{ihnp4,decvax,ucbvax}!tektronix!hammer!steveh
  Tektronix GWD Networking	(503)685-2103