rlogin excites an obscure, intermittent kernel bug:
sometimes, send(..., MSG_OOB) will return successfully & report
that a character was sent, but the recipient will never get the character.
this manifests itself in rlogin as the "need to resize at rlogin startup"
bug, which shows up best when:
	the remote host is more heavily loaded than the local host;
	rlogin is reinvoked immediated after a rlogin session is logged out.

   make sure the remote .login and .cshrc don't invoke resize, and invoke
"man csh" immediately on rlogin startup. if the bug is active, more will
not fill the screen correctly. it may take several (~10) successive rlogins
to get a fucked-up screen in this way. if you wait around 3 minutes (?)
between successive rlogins, the bug is less likely to appear.
   the send bug causes the resize problem, because the rlogin server asks 
the client to send window-sizes with an out-of-band message. when the bug
is active, the daemon asks repeatedly, but the client never gets the request.
strangely, environment-passing, which also relies on oob-traffic, is unaffected.
   once an rlogin session shows this bug, it will continue to suffer until
either: 1) resize is executed on the remote shell, or 2) ^C is hit.
I don't know why ^C works; i've tried to figure it out.
   to monitor the oob-traffic, compile rlogin's sources with -DDBG as a
cc option,or run its makefile with DBG=-DDBG. the local debugging output
goes to /tmp/cdbg (client's stuff), and the server's goes to /tmp/sdbg
(server's stuff) on the remote machine. when the server sends a request,
the lines ">>send_oob:..." and "<<send_oob..." appear in sdbg. if the bug isn't
active, cdbg will show that readeroob was invoked, and the line
"oob_char arrived:..." means that the reader successfully peeked (MSG_PEEK)
at the oob-character.
   if the bug is active, readeroob will be invoked just once, for env-passing,
and not thereafter, and reader will not see any oob-messages coming in on the 
socket. this means that the oob-mark isn't getting set in the rem-to-loc
socket stream, and that the SIGURG isn't getting raised.
i infer that the oob-data isn't getting to the recipient.
The socket in question is not a datagram socket.
   see don davis for more info.
