科技行者

行者学院 转型私董会 科技行者专题报道 网红大战科技行者

知识库

知识库 安全导航

至顶网网络频道Second thoughts on Telnet Go-Ahead(1)

Second thoughts on Telnet Go-Ahead(1)

  • 扫一扫
    分享文章到微信

  • 扫一扫
    关注官方公众号
    至顶头条

In this RFCwe present objections to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372).

作者:论坛整理 来源:ZDNet网络安全 2007年12月25日

关键字: telnet命令 opentelnet linux telnet telnet入侵 telnet telnet端口

  • 评论
  • 分享微博
  • 分享邮件

  Network Working Group E. Taft

  Request for Comments: 596 PARC-MAXC

  NIC: 15372 8 December 1973

  Second Thoughts on TelnetGo-Ahead

  INTRODUCTION

  In this RFCwe present objections to the requirement that hosts implement the Telnet Go-Ahead (GA) command, as specified in the Telnet Protocol Specification (NIC #15372). The thrust of these objections is in three major directions:

  1. The GA mechanism is esthetically unappealing, both to myself and to many other people I have talked to. I shall attempt to describe why this is so.

  2. As specified in the Protocol, GA will not, in general, work; i.e. it will not serve its intended purpose unless hosts make various unwarranted assumptions about how other hosts operate.

  3. GA is impossible for most hosts to implement correctly in all cases. This is certainly true of the PDP-10 operating systems with which I am familiar (10/50 and Tenex).

  The purpose of this RFCis to advocate either complete removal of the GA mechanism or relegating it to the status of a negotiated option whose default state is that it be suppressed.

  TERMINOLOGY

  "Half-duplex" is a two-way communication discipline in which transmission takes place in only one direction at a time and the receiving party is constrained not to transmit until the transmitting party has explicitly given up control of the communication path ("turned the line around").

  This definition is distinct from a common (but incorrect) use of the terms "half-duplex" and "full-duplex" to designate local and remote character echoing.

  "Reverse break" is a means by which a computer connected to a terminal by a half-duplex path may regain control of the path for further typeout after previously having relinquished it. This is the complement of the "break" or "attention" mechanism, implemented by all half-duplex terminals, by means of which the user may gain control of the line while it is in use by the computer.

  ESTHETIC OBJECTIONS TO GA

  One assumption that permeates the Telnet Protocol specification (and is explicitly stated on Page 7) is that the "normal" mode of communication between computers and terminals is half-duplex, line-at-a-time. While historically this is partially true, it is also clear, both within the ARPA Network community and elsewhere, that the trend is toward highly interactive man-machine communication systems which are difficult to implement under half-duplex communication disciplines.

  The GA mechanism is an attempt to solve a specific problem, that of switching control between computer and user in a subset of those hosts utilizing IBM 2741 or equivalent terminals. I say "a subset" because in fact the problem arises only in the case of TIPs from 2741s (with reverse break); from what experience I have had, I think the TIP does a very good job of turning the line around at the right moments. (I am told this is also the case at Multics).

  Given the trend toward more interactive communication, and given the fact that terminals on the Network requiring a Go-Ahead mechanism are a distinct minority of all terminals, I think we should be reluctant to burden our protocols with kludges that are so clearly a concession to obsolete design.

  I have little doubt that before long somebody (if not IBM) will produce a full-duplex 2741-like terminal (indeed, perhaps it has already been done). There is an obvious need for a terminal with Selectric quality keyboard and hard-copy better suited to interactive applications (i.e. full-duplex).

  As a more practical consideration, it makes little sense to have the default state of the GA option be the one that benefits the least number of hosts and terminals.

  There is no question that most parties to Telnet communication will immediately negotiate to suppress GA. To do otherwise will double the amount of network traffic generated by character-at-a-time typein, and will increase it by a non-negligible amount even for a line-at-a-time typein.

  It strikes me as worthwhile to minimize the number of such "necessary" option negotiations, especially in view of the large number of TIPs and mini-hosts on the Network. Many such hosts must, due to resource constraints, implement only a limited subset of the available options. It follows, then, that the default state of all options should be the one most hosts will be willing to use.

  WHY GA WON'T WORK

  We now show that a server process's being "blocked on input" (as specified in the Protocol) is not itself a sufficient condition for sending out GA. 

       This is due to the fact that the user Telnet has no control over the packaging of a "line" of information sent to the server; rather, this is a function of the NCP, which must observe constraints such as allocation and buffering. Consider the following example: A user types a line of text, which is buffered by his host's user Telnet until he signals end-of-line. His keyboard then becomes locked (this being the behavior of half-duplex terminals while the computer has control of the line), and stays locked in anticipation of the server's eventual response and subsequent GA command.

    • 评论
    • 分享微博
    • 分享邮件
    邮件订阅

    如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。

    重磅专题
    往期文章
    最新文章