[Simh] Question on telnet mantra in simh
J. David Bryan
jdbryan at acm.org
Wed Nov 10 22:17:36 EST 2010
Hi Holger,
On Tuesday, November 9, 2010 at 9:15, Holger Veit wrote:
> while implementing telnet support in my terminal emulator, I came
> across the "Telnet Mantra" in sim_tmxr.c:
>
> [...]
>
> I think I understand that the simh terminal multiplexer is a server in
> telnet speech, accessed by some sort of telnet client program operated
> by the user.
The SIMH multiplexer library is intended to implement a Telnet server, but
it does not. I had been in contact with Arthur Krewat, the original
implementor of the module, back in 2007 about this problem. He stated
essentially that the code is a hack that worked with the clients in use at
the time. No attempt was made at RFC compliance or proper negotiation.
My observations at the time were:
1. SIMH sends "WILL LINEMODE", "WILL SUPPRESS-GO-AHEAD", and "WILL ECHO",
but it takes no action based on the acceptance or rejection of these
offers by the client. If "WILL ECHO" is accepted with a "DO ECHO",
for instance, SIMH should start echoing received characters. It
doesn't, as far as I can see.
2. SIMH sends "WILL BIN" and "DO BIN" to request binary transmission in
both directions. It responds to "WONT BIN", meaning no binary
transmission from terminal to SIMH, but ignores the "DO BIN" or
"DONT BIN" for the SIMH-to- terminal connection. Also, it assumes
binary mode in the absence of a reply (WILL or WONT from the
terminal), but the RFC requires that it remain in ASCII mode in this
case.
3. SIMH ignores WILL or DO requests it does not understand, rather than
rejecting them with DONT or WONT (not responding implies that SIMH
is already in the mode offered -- "If a party receives what appears
to be a request to enter some mode it is already in, the request
should not be acknowledged").
Rewriting the Telnet code to implement an RFC-compliant server was on my
"to do" list at the time, but I found that there were complications. For
example, the HP terminal emulator "QCTerm" does not follow RFC 854, which
requires that CR characters be followed either by LF or NUL in ASCII mode.
QCTerm sends bare CRs, so an RFC-compliant server would lose the first
character of each line transmitted. There is a workaround in the code for
this; see my comment in "sim_tmxr.c".
The priority for creating proper server negotiation dropped for two
reasons. First, the current code seems to work with clients in use.
Second, at least some clients in use aren't RFC-compliant themselves, so
implementing a strict RFC-compliant server likely would break existing
configurations and would require workarounds. So it seemed to be a lot of
work for marginal benefit.
> So I think, the first line is at best useless, and should be removed,
> or, perhaps better, replaced by a IAC WONT LINEMODE.
I believe that sending "WONT LINEMODE" upon connection is prohibited by the
RFC ("Parties may only request a change in option status; i.e., a party may
not send out a 'request' merely to announce what mode it is in").
-- Dave
More information about the Simh
mailing list