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.

Relevant Pages

  • Re: [OT] CNN bragging about "FTP technology"
    ... The specs for addresses aren't TCP, ... > data packets are put together in the right order at the receiving end; ... The machine, or physical layer, comprises ... The network layer has to do with addresses, ...
  • Re: NDIS miniport Driver - packet re-ordering
    ... receiver issue? ... You might fail on WDK NDIS testing if your packets are not ordering. ... I've reviewed the TCP / IP Layer concepts in ...
  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
  • Re: Simulating smaller MTU? ie sending small packets.
    ... This is due to the fact that TCP ... If you want smaller packets, ... >> set there as the MSS is announced by the receiver during the ... Yes, per connection. ...
  • Re: NTP and Firewall help needed.
    ... >port 123 for udp and tcp. ... Also the idea of combining rules for packets arriving at the local machine ... ACCEPT any and all traffic coming from the localhost interface ...