Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.4bsd
Subject: Re: rlogin drops output when stop/start characters change
Message-ID: <1451@umcp-cs.UUCP>
Date: Fri, 30-Aug-85 22:26:53 EDT
Article-I.D.: umcp-cs.1451
Posted: Fri Aug 30 22:26:53 1985
Date-Received: Sun, 1-Sep-85 05:49:41 EDT
References: <3216@mordor.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 25

> "rlogin" cannot simply recv() the out-of-band message because it
> uses the position of this message among the in-band data to determine
> how much output must be flushed.  (It does this with the undocumented
> SIOCATMARK ioctl.)

Undocumented it is not: the 4.2BSD IPC primer explains SIOCATMARK.
Would that this were not the only place.

> In order to handle this properly, it must "peek" at the message
> first to determine its contents, flush output if necessary, and
> then recv() the message and take any other appropriate actions.

It is interesting to note that recv(fd, buf, len, MSG_OOB) and
recv(fd, buf, len, MSG_OOB|MSG_PEEK) perform the same operation.
OOB data is only consumed in the kernel by reading the in-band data
past the out-of-band mark.  This is odd at best.  In addition some
of the kernel code that implements out of band data is very strange.

I would suggest that you check the return values from the two recv
calls.  I'm not yet convinced that this fix actually does the right
things, if only because the OOB kernel code is so odd.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland