Re: RFCS - Telnet commands mixed with 3270 data

[Tom Schlender <[e-mail]>]

Bob said:
> >>Opinions on which way we should go on IACs within a 3270
datastream will
> >>be solicited until the end of the week.  I would like to have the last
> >>call on IETF issued on this before the Thursday of next week
>
> Eddie Renoux said:
>
> >I like having no TELNET IACs within the TN3270 datastream.  This
would make
> >the examination of the datastream that the server has to do much
easier.
> >It would also eliminate the possibility of confusion if a "pseudo"
ATTN
> >(IP) were found (allowed) in the middle of a TN3270 datastream.
> >(I realize the server still has to strip the doubled IACs.)
>
> Let me restate a couple of points.
>
> IAC doubling is the way the TELNET protocol works in 8 bit mode.
There is
> no way around it.  There are only two ways for us to avoid it.
>
> #1      Get off port 23.  --  Not likely.
>
> #2      Develop a Finite State Automata that would go into the RFC that
>         would definitively explain the logic flow to handle intermixing
>         and mix ups of real TELNET and our no IAC doubling.  I called for
>         this FSA back in June, I think, and since no one has come
forward,
>         I do not see us delaying everything even longer to work it out
and
>         to get a lot of people feeling comfortable that we have covered
all
>         of the cases.
>
> ERGO, IAC doubling will be an integral part of RFCS.
>
> Next question is will we avoid real IACs between the start of a data
block
> and the EOR?
>
> It seems like for debugging purposes it would be best to do that (and I
have
> done a fair amount of TN3270 debugging in the past year). I fail to see
what
> logic processing it would save the vendors (and thus preformance
> improvements) given that they have to scan for IAC doubling and IAC
EORs
> anyway.  But then I don't write code.
>
> Bob
>

You are right, if the data block must be scanned for IAC doubling and
IAC EORs, then there would be no performance improvement obtained
from prohibiting Telnet commands within the data block.  When the first
IAC is found, the next byte must be checked to determine the meaning
of the IAC.  The problem is having to scan the data, not finding a
Telnet command within the message block (which I doubt happens
very often).

To obtain a performance improvement, a field would be required in the
message header that would indicate the length of the message block.
Then, within this message block IAC doubling and Telnet commands
would not be allowed.  Telnet commands or option negotiations would
occur outside of the message block.

Any performance improvement obtained from such a scheme probably
would not affect a client's processing or a server with a relatively
small number of connections.  But it is an issue for a server with
a large number of concurrent sessions (eg., 10,000).
Tom Schlender                    [e-mail]
Unisys Corporation               Phone: [phone]
Roseville, MN