RE: Timeout strategy: terminal vs Telnet drivers

Please do not send me Discourtesy copies of newsgroup posts.

In article <JFEPKAPBPMDFDBOIANGDKEJGHBAA.dallen@xxxxxxxx>, "Dan Allen" <dallen@xxxxxxxx> writes:
>> -----Original Message-----
>> From: Larry Kilgallen [mailto:Kilgallen@xxxxxxxxxxx]
>> Sent: Tuesday, December 13, 2005 4:03 PM
>> To: Info-VAX@xxxxxxxxxxxx
>> Subject: RE: Timeout strategy: terminal vs Telnet drivers
>> In article <JFEPKAPBPMDFDBOIANGDIEINHBAA.dallen@xxxxxxxx>, "Dan
>> Allen" <dallen@xxxxxxxx> writes:

>> > Exactly - the Telnet application may WRITE individual characters but the TCP/IP
>> > layer may or may not send them as individual packets. TTBOMK applications have
>> > no control over that phase of the network exchange - and for good reason.
>> The context was "keystroke" and "echo", thus unrelated to application
>> output.
> The context was Telnet which IS an application (client and server) wrt TCP
> connections.
>> Applications have control over character input when they specify
>> the termination characters they want honored. VMS SET HOST passes
>> that information on to the system where the user is located and the
>> transmission is made only when the requirements of the application
>> have been satisfied. "Tell me after every character" is a possible,
>> but rarely useful, possible set of requirements, even for TECO.
> I fail to see your distinction. Telnet and TCP are no different - they behave
> the same way.

But DECnet on VMS is different.

> If you don't want the remote Telnet server to echo your keystrokes
> just turn it off. If you want your local Telnet client to echo your keystrokes
> turn it on. If you want Telnet to defer transmitting keystrokes until you hit CR
> turn it on.

That involves some manual fiddling on the part of the user, or else a
program specifically written for use with Telnet.

> None of that changes the fact that the TCP (and Decnet) transport layer will
> decide how to best packetize that data when it is actually sent over the network
> link - not the "applications".

No, SET HOST responds to what the _application_ has told TTDRIVER --
transmitting after the characters <SOH>, <VT>, but not <CR> (for
example), and provides all the keyboard characters to the TCP connection
in a single group. Yes, TCP could divide it for packet size limits,
but it will not be dividing it based on typing speed (for example).

SET HOST performs local echo (or not) depending on the QIO control
settings by the application at the other end of the pile.