Toad的博客

点击下载：[PDF]RFC1091_TELNET终端类型选项_中文版

简介

在RFC821（"SIMPLE MAIL TRANSPORT PROTOCOL"，SMTP，简单邮件传输协议）的附录D中提到了直接将SMTP置于X.25虚电路（ISO第3层）上的可能性。并建议“利用一种类似于TCP可靠的端到端协议在X.25的连接上”。在1981年时，考虑到PSDNs的总体的可靠性，这毫无疑问是可行的。这一业务现在（1989年）已经非常可靠，它允许直接将其置于虚电路业务上。

在包括22个不同的国家的24个PSDN网的许多产品，证明了这种方法是成功的，结果证明，即使使用在一些花费比较昂贵的PSDN中，这种方法还是十分经济的，在X.25专网和X.25局域网中，这种方法也是成功。

每一个SMTP会话必须打开一条X.25虚电路（Virtual Circuit ，VC），SMTP会话将使用由VC提供的全双工通道。通常，VC是由发起呼叫的一方关闭的。

点击下载：[PDF]RFC1090_SMTP在X.25_中文版

序言

本文档旨在给出在NetBIOS网络上传输IP数据报的具有兼容性和互操作性的实现方法。

NetBIOS标准描述了创建虚拟电路并发送和接收点对点、多点传送和广播数据报的一种方法。本规范仅用了数据报服务。

本备忘录的前期版本使用NetBIOS 广播数据报服务代替NetBIOS组名服务实现IP广播。 现在这些版本已经作废。

点击下载：[PDF]RFC1088_IP 数据包传输通过NetBIOS网络的标准_中文版

简介

在IP网络上多播的草拟标准目前存在[2]，但没有支持网间多播的路由选择协议。本备忘录描述了实验性的路由选择协议，叫做DVMRP，它实现了网间多播。DVMRP使RIP中的许多特性和在Deering[3]中所描述的截断方向路径广播（TRPB）算法相结合。

DVMRP是一个“内部网关协议”；适合在自治系统内的使用，但不能在不同的自治系统之间使用。当前开发的DVMRP不能用于为非多播数据报选路，因此要想一个路由器既能为多播数据报又能为单播数据报选路，则它必须运行两个分离的路由选择进程。DVMRP被设计成易于扩展的，可以扩展成为单播数据报选路。

开发DVMRP是为了试验[3]中所描述的算法。RIP用作这次开发的起始点是因为有一个实现版本可用，而且距离矢量算法与连接状态类算法[4]相比较简单的。另外，为了试验穿越不支持多播的网络可行性，开发了一种叫“隧道”的机制

多播转发算法需要构建基于路由信息的树。构建这颗树需要的状态信息比RIP被设计能提供的要多。因为DVMRP在某些方面比RIP复杂的多。已经具有许多所需要的状态的连接状态算法，可能为Internet上多播选路和转发提供了更好的基础。

DVMRP在一个非常重要的方面与RIP有不同之处。RIP按照路由和转发数据报的方式思考。 DVMRP的目的是为了了解到多播数据报出发地的返回路径。为了将DVMRP解释的和RIP一致，单词“目的地”用来代替更恰当的“出发地”但读者应该记住数据报并不被转发到这些目的地，而是起源于那里。

本备忘录被组织为下列部分：

—对DVMRP进行描述。

—解释隧道。

—展示路由算法。

—展示转发算法。

—列出不同的时间值。

—说明配置信息。

本备忘录不分析距离矢量路由，也不充分解释距离矢量算法；要想获得这方面主题的更多信息，请参看[1]。在本备忘录中执行路由和转发功能的一个进程或多个进程被称作“路由器”。

点击下载：[PDF]RFC1075_远距离矢量多播选路协议_中文版

随着窗口系统的日益流行，Telnet客户端总是运行在一个可变尺寸的窗口中。Telnet服务器为了正确控制光标，需要知道窗口的尺寸。窗口可能在Telnet的会话过程中改变尺寸，更新的窗口尺寸需要传送给服务器。本备忘录就确定了一个从客户端到服务器发送用字符表示的窗口高度和宽度的选项。

Telnet选项：协商输出行宽（NAOL）和协商输出页尺寸(NAOP)在语义上并不是很恰当，他们不是公用的[见RFC-1011 "正式Internet协议",和"防卫协议手册"]。NAOL和NAOP选项是双向的（也就是说服务器可以控制客户端的行宽或者页尺寸），在每一轴中限制253个字符。

这个选项是正常窗口协商过程的一个较好的模型。客户端完全控制它的窗口尺寸，只是简单地告诉服务器当前的窗口是多大。而且，253个字符的高度和宽度的限制非常低，所以，新的选项具有65535字符的限制。最后，这个选项同时发送窗口的高度和宽度，因为窗口高度和宽度通常都是同时改变的。许多操作系统和窗口应用程序更可能认为窗口的高度和宽度是同时改变的。

点击下载：[PDF]RFC1073_Telnet窗口大小选项_中文版

RPC模式

Sun RPC协议基于远程过程调用模式,它类似于本地过程调用模型.在本地调用方式中,调用者把参数放在公众指定地点(如注册窗口),然后发送控制到过程,最后重新获得控制.接着,从指定地点取出过程结果,调用者继续执行.

远程过程调用相类似.控制线程在两个过程中逻辑转换:调用过程和服务过程.调用过程首先发送一个调用信息到服务过程然后等待应答信息.调用信息包括过程参数,应答信息包括过程结果.一旦接收到应答信息,就取得过程结果,然后调用执行继续进行.

在服务器端,过程保持睡眠状态到调用信息的到达.当一个调用信息到达,服务器获得过程参数,计算结果,发送应答信息,然后等待下一个调用信息.

在这种模型中,任何时间里两个过程只有一个激活.但是,该模型只是作为一个例子.Sun RPC协议对并行模型执行没有限制,但是其它的有可能不一样.例如,一个应用程序可能选择RPC调用为异步的,因此客户端只有等到服务器端的应答才做有效工作.另外一个可能是使服务器端生成一个新的任务来处理进来的调用,因此最初的服务器可以处理其他请求. 远程调用和本地过程调用有几个重要区别:

1.错误处理:在远程过程调用中，网络或远程服务器的失败必须处理.

2.全局变量和副作用:因为服务器没法访问客户地址空间,隐藏的参数不能用全局变量传递或返回副作用.

3.表现:远程过程操作比本地过程调用慢一到几个数量级.

4.鉴定:因为远程过程可以在不安全的网络中传输,必须采用鉴定.

结论是即使有工具自动为给定服务产生客户或服务器库,仍然必须仔细设计协议.

点击下载：[PDF]RFC1057_RPC远程步骤呼叫协议说明书版本 2_中文版

简介

TCP/IP协议组运行在各种各样的网络媒介上：IEEE 802.3（以太网）和802.5（令牌环）局域网（LAN）、X.25线路、卫星链路以及串行线路。其中许多网络已经有IP分组的标准封装格式，但没有用于串行线路的标准。SLIP（串行线路IP）目前已成为事实上的标准，广泛地用于在点对点串行连接上运行TCP/IP。这并不是一个Internet标准，本备忘录的发布不受限制。

点击下载：[PDF]RFC1055_在串行线路上传输IP数据报的非标准协议_中文版

简介

此文档详细说明了一个使用在实现Sun公司的远程过程调用(RPC)包中的消息协议。此消息协议是由外部数据描述(XDR)语言[9]来定义的。这篇文档假定读者对XDR非常熟悉，它并不试图去证明使用RPC的好处。这里推荐由Birrell and Nelson [1]所写的文章，作为了解RPC的背景。

点击下载：[PDF]RFC1050_RPC远程步骤呼叫协议说明书_中文版

摘要

这一改进有效地拓展了核心系统的概念使其涵盖多个自治系统社区——称之为自治联邦，现有的实现无需修改就可以与增强的实现协同工作。与一般的自治系统之间相比，自治联邦维持了更高的互信度，包括避免成员系统之间出现路由循环的合理保护，但是允许放宽当前EGP模型的路由限制。

改进包括EGP更新消息的“跳数”或者距离字段，当前的EGP模型没有纳入对这一字段的解释。每个自治联邦对这个字段都给出了特定的解释以支持最多三层的路由：一是在自治系统内，二是在自制联邦内，三是在联邦全体内，其中第三层是可选的。

点击下载：[PDF]RFC975_自治联邦_中文版

简介

本备忘录的目的在于阐明邮寄方如何确定以给定的Internet域名为地址的消息的发送路由。其中包括关于邮寄方如何解释MX RR的讨论，MX RR用于消息路由。注意，本备忘录没有涉及邮寄方如何处理MB RR和MG RR的陈述，这两者用于邮箱名的解释。

RFC 882和RFC 883中关于邮件地址的一些设想已经发生了变化。现在一般可以认为如果消息的地址是一个信箱——比如LOKI.BBN.COM，只要打开一个对LOKI.BBN.COM的SMTP连接向前发就可以了。这种系统不适用于某些特定的情况，比如没有直接接入Internet的特定的UUCP和CSNET主机，不过这些主机可以在配置文件中作为特殊情况处理（比如大部分邮寄者都设定把发送给CSNET的邮件自动转发给CSNET-RELAY.ARPA）。

在域名系统中不能简单地打开对LOKI.BBN.COM的连接，而必须向域名系统询问发往LOKI.BBN.COM的消息如何递送。域名系统可能会指导邮寄者把消息传递到一个完全不同的主机，譬如SH.CS.NET。或者在更加复杂的情形中，邮寄者可能得知它有一个到LOKI.BBN.COM的路径可以选择。本备忘录主要讲述在这种更加复杂的情况下邮寄者如何工作的一些指导原则。

希望读者已经熟悉了RFC 882、RFC 883和它们的更新版本（如RFC973）。

点击下载：[PDF]RFC974_邮件路由与域名系统_中文版