Subject: read without echo

From: [email-masked] (Eric Weber)
Date: Sun, 18 Apr 1993 00:10:00 -0700

Has anyone implemented an option to do a read() without echoing to the user?  

I know how to enable and disable echoing on a socket, but I can't figure out
how the MOO read() function actually works.  I can't seem to locate where the
server actually determines that the string it got from the socket needs to be
given to a running task rather then parsed as a command.  The actual bf_read  
function doesn't seem to actually do much.

If someone could enlighten me on the gory details of read(), I would be
eternally grateful.

-- Eric

---

From: Judy Anderson <[email-masked]>
Date: Sun, 18 Apr 1993 14:19:58 -0700

I thought the MOO didn't echo anything at all, and it was your client
that was doing the echoing for you...  You'd have to do some client
negotiation to get it to turn off echoing for you.

---

From: [email-masked] (Eric Weber)
Date: Sun, 18 Apr 1993 16:08:15 -0700

Inded, the client does do the echoing.  However, the telnet RFC describes a
protocol whereby the server can ask the client to turn echoing on or off.  
This will work for many (but not all) clients.  The problem is where to insert
this code in the server.

-- Eric

---

From: Greg Hudson <[email-masked]>
Date: Sun, 18 Apr 1993 17:29:58 -0700

> However, the telnet RFC describes a protocol whereby the server can
> ask the client to turn echoing on or off.  This will work for many
> (but not all) clents.

The RFC which describes the telnet echo option is not the telnet RFC
(854) but RFC 857.  This is just a minor nit.

As for clients, this will work with VT as of version 2.15, TF as of a
recent version, with Uush, with some version of mud.el (but not
moo.el, as far as I know), and of course telnet.

The vast majority of MOOers probably use moo.el or TF, and probably
versions of TF that don't support the telnet protocol.  This means
they will see funny-looking characters or extra spaces when the server
sends the IAC WILL ECHO or IAC WONT ECHO.

While we're talking about server-client communications, I should talk
about prompt protocols.  VT 2.15, new versions of TF and TUsh, and
some version of mud.el support the IAC GA prompt protocol.  This means
that if the server sends a partial line (not terminated with a
newline) and then an IAC GA, the client will treat the text as a
prompt.  Users of old clients will see funny characters or extra
spaces.

VT 2.15 and new versions of TUsh also support the IAC EOR prompt
protocol.  Under this protocol, the server negotiates with the client
to turn on the option, sending an IAC WILL EOR and turning on the
option when it receives an IAC DO EOR.  Then it sends IAC EOR
sequences after prompts just as above.  Users of old clients will see
funny characters or spaces on startup, but not afterwards.

A nit on the IAC EOR protocol: the server has to be careful with
prompts at login time.  If a server using this protocol receives the
IAC DO EOR while prompted input is pending, it should immediately send
an IAC EOR.

RFC 854 describes the IAC GA sequence along with the telnet protocol.
RFC 885 describes the telnet EOR option.  Neither were intended as
prompt terminators, although one could argue that prompts fit into the
general idea of either one.

I'm not sure whether it's a good idea to put these things into MOO.
Ken Keys and I pushed for prompt protocols because of the existing
LPmud server, not because we thought prompts were a great thing.
Sticking to line-based communication with no fancy maneuvers has an
aesthetically pleasing simplicity.

--GBH

---

From: Pavel Curtis <[email-masked]>
Date: Tue, 20 Apr 1993 09:39:15 -0700

> Date:	Sun, 18 Apr 1993 00:10:00 -0700
> From:	[email-masked] (Eric Weber)
> 
> ... I can't figure out how the MOO read() function actually works.  I can't
> seem to locate where the server actually determines that the string it got
> from the socket needs to be given to a running task rather then parsed as a
> command.  The actual bf_read function doesn't seem to actually do much.
> 

The functions read() and suspend() are supported by special magic in the MOO
interpreter.  On return from the bf_* routines for these functions, if no error
is to be signalled, the interpreter bundles up the state of the task and calls
into the task manager to save the suspended task in the appropriate place.  For
read()ing tasks, this is attached to the task queue for the player whose
connection is being read.  The next time an input line is to be processed for
that connection, the read()ing task is noticed and resumed, with the read()
call returning the input line.

The relevant code is in the OP_BI_FUNC_CALL case of the interpreter (in run()
in execute.c), and in make_reading_task() and run_ready_tasks() in tasks.c.

	Pavel/Haakon/Lambda