尊重作者 转载请注1.winsock错误信息
常数 值 描述
sckOutOfMemory 7 内存不足
sckInvalidPropertyValue 380 属性值无效。
sckGetNotSupported 394 属性不可读。
sckSetNotSupported 383 属性是只读的。
sckBadState 40006 所请求的事务或请求本身的错误协议或者错误连接状态。
sckInvalidArg 40014 传递给函数的参数格式不确定，或者不在指定范围内。
sckSuccess 40017 成功。
sckUnsupported 40018 不受支持的变量类型。
sckInvalidOp 40020 在当前状态下的无效操作
sckOutOfRange 40021 参数越界。
sckWrongProtocol 40026 所请求的事务或请求本身的错误协议
sckOpCanceled 1004 取消操作。
sckInvalidArgument 10014 所请求的地址是广播地址，但未设置标记。
sckWouldBlock 10035 套接字不成块，而指定操作将使之成块。
sckInProgress 10036 制造块的 Winsock 操作在进行之中。
sckAlreadyComplete 10037 完成操作。未进行制造块的操作。
sckNotSocket 10038 描述符不是套接字。
sckMsgTooBig 10040 数据报太大，不适于缓冲区的要求，因而被截断。
sckPortNotSupported 10043 不支持指定的端口。
sckAddressInUse 10048 地址在使用中。
sckAddressNotAvailable 10049 来自本地机器的不可用地址。
sckNetworkSubsystemFailed 10050 网络子系统失败。
sckNetworkUnreachable 10051 此时不能从主机到达网络。
sckNetReset 10052 在设置 SO_KEEPALIVE 时连接超时。
sckConnectAborted 11053 由于超时或者其它失败而中止连接。
sckConnectionReset 10054 通过远端重新设置连接。
sckNoBufferSpace 10055 没有可用的缓冲空间。
sckAlreadyConnected 10056 已连接套接字。
sckNotConnected 10057 未连接套接字。
sckSocketShutdown 10058 已关闭套接字。
sckTimedout 10060 已关闭套接字。
sckConnectionRefused 10061 强行拒绝连接。
sckNotInitialized 10093 应首先调用 WinsockInit。
sckHostNotFound 11001 授权应答：未找到主机。
sckHostNotFoundTryAgain 11002 非授权应答：未找到主机。
sckNonRecoverableError 11003 不可恢复的错误。
sckNoData 11004 无效名，对所请求的类型无数据记录。
2.汉化的RFC 854,TELNET章节
TELNET协议规范
ARPA Internet上的主机被要求采用并实现此标准。
介绍
TELNET Protocol的目的是提供一个相对通用的，双向的，面向八位字节的通信方法。它主要的目标是允许接口终端设备的标准方法和面向终端的相互作用。可以预见到，此协议也可被用于终端到终端的通信和处理到处理的通信（分布式计算）。
一般考虑
一个TELNET连接是一个用于传输控制协议的传送数据的。TELNET 协议是建立在以下三个想法上的：首先是网络虚拟终端的概念；其次是对话选项的方法；最后是终端和处理的协调。
当一个TELNET连接被初次建立时，每一端都被假设使用了网络虚拟终端，也就是NVT。NVT是一个想象中的标准设备通用设备的代表。这就消除了“服务器”和“用户”机要了解对方机器终端的特点，而终端可以直接处理对话。所有的主机，用户端的和服务器端的，它们自己本地的设备特点因此在网络上可以作为一种NVT处理，任何一个都可以认为对方使用的是相同特点的设备。NVT倾向于不过多地限制（提供了一个相应比较丰富的映射到本地设备的字符集），也不是包括一切的（它要求用户使用适当的终端）。注意：用户机通常是与处理终端连接的主机，服务器机通常是提供某种服务的机器。从另一点看，在终端到终端或进程到进程的通信上，用户机是发起通信的机器。
规定选项的原理将以下事实考虑在内，许多机器希望在现在的NVT上提供另外的服务，多数用户有比较复杂的终端，它们也就希望一种比较完整的而不是最小的服务。独立的，但是存在于 TELNET 协议的不同选项支持这些需求，它们使用"DO, DON'T, WILL, WON'T" 结构允许用户机和服务器建立建立一种更加精巧的TELNET会话连接。这种选项包括改变字符集，响应模式等等。设置选项的基本策略是任一方（或者两者）初始化要求一个选项生效的请求。另一方可以接受也可以拒绝这一请求。如果接受请求，此选项立刻生效；如果被拒绝，连接仍然保持基本的NVT的连接属性。很明显，一方可以拒绝另一方关于启用某一选项的请求，但是不能拒绝另一方关于使一选项失效的请求，因为双方必须准备支持NVT。对话选项语法的建立使在双方都发出请求某一选项生效的请求时，另一方可以直接认为收到对方的确认信息。
这种对称式的对话语法潜在地引起了一个不可终止的确认环--任何一方都将收到的确认信息看作是请求，而不是一个确认信息。为了防止这种循环的出现，有下面的规则：
任何一方仅可以要求对选项状态的变化：例如，一方不可以发出请求，仅仅说明它在什么样的选项状态下。
如果一方接收到好象是请求的信息，请求进入一个已经进入的状态，此信息将被看作是一个确认消息。这种非响应从本质上防止了不可终止的对话的循环。如果要求发送一个要求改变状态的请求，即使状态并未改变。
无论何时，一方发送选项命令到另一方，无论作为一个请求或者是一个确认消息，选项的使用将对发送的数据处理有影响，这样命令应该被插入到希望发生作用的数据流中的数据点之前。（应该注意，传送请求和收到确认消息之间有一定的时间间隔，这是被动方式的。因此，一个主机希望在要求一个选项后缓存数据，直到它知道它的请求是否被接受，这样就可以使这段不不确定时间对用户不可见。）选项的请求可以在建立TELNET连接时十分频繁地来往交换，因为每一方都希望从对方得到更好的服务。
除此以外，选项也可以在连接持续过程中动态改变来适应本地机器条件的变化。例如，NVT（它将以后被详细解释）对于许多“一次一行”的应用程序，如BASIC是十分适用的，而对于如NLS的“一次一字”的应用程序却不怎么好用。服务器可能被选择作为“一次一字”法则来适应在其上运行的本地进程，它将发起对话以达到合适的选项状态。然而，相对于永久地负责这种多余的处理负担；它可以通过会话，在不需要这样的选项状态下回到NVT状态。由一个进程发起的请求可以导致一个不可终止的请求循环，如果此进程对一个拒绝请求的响应是再次要求此选项。为了防止这样循环的发生，被拒绝的请求在其它事情发生变化之前不能被重复请求。这可能意味着，进程运行另外一个程序，或者用户发送另外的命令，或者用户对于环境或选项的改变。
比较好的方法是，预请求应该作为由另一端发送信息的结果而发生，或者由于人为介入而发生。选项的设计者不应该因为对于选项会话的种种限制而感觉到伸不开手脚。一般语法的目的是更容易地拥有选项--因为表示对它们的忽视也是容易的。
如果特定的选项需要除"DO, DON'T, WILL, WON'T"以外的更丰富的结构，正确的方针是使用"DO, DON'T, WILL, WON'T"来建立连接解释这种新结构，当这一解释工作完成时，就可以自由地使用这一新结构了。例如，一方可能发送请求改变（或建立）每行的长度。如果接受了这些，对于对话的不同行长度可以使用不同的语法来表示--“子对话”可以包括一个域表示最大允许的，最小允许的和希望的长度。重要概念是这样的扩充的会话应该直到双方建立了标准的会话并且能够解释这种扩充的语法之后再进行。总的来说，WILL XXX发送时说明一方希望执行选项XXX，DO XXX 和 DON'T XXX作为确定的不确定的响应；同样，DO XXX被作为一种请求发送给另一方来启动选项XXX，WILL XXX 和WON'T将被作为确定和不确定的响应。因为NVT是没有任何选项时的结果， DON'T和WON'T响应将保证使连接最终保持于这种没有任何选项的状态。因此，所有主机可以不支持不理解的选项，它仅仅需要返回这种选项的请求即可。
尽可能的，TELNET协议被用作服务器-用户的对称，这样，它就可以更容易而自然地处理用户-用户和服务器-服务器的情况。用选项来扩展这一功能是被希望实现的，但不是必要的。在任何情况下，对称是一个运行的准则而不是固定的准则多次被明确提出。一个比较文档，“TELNET选项说明”，可以被用于对建立新选项过程信息的参考。
网络虚拟终端网络虚拟终端（NVT）是一个双向字符设备。NVT有一个显示设备和一个键盘。显示设备响应到达的数据，键盘负责通过TELNET连接发送数据，如果需要回显，也应该在NVT的显示设备上显示。对于网络上的回显并不要求（虽然确实存在这个“远程”回显选项，但是主机必不是必须实现此选项）。字符集是由七位ASCII码组成的，而保存在八位的域中。任何字符的转换和计时方面的考虑都是本地的问题，这不影响NVT的工作。
数据传送方面，虽然TELNET连接是全双工的，NVT却是在线缓冲状态下的半双工设备。传送数据 虽然TELNET连接是全双工的，在线缓冲模式下，NVT却被当作半双工的设备。此信号可以由进程或者用户产生。对于一些主机处理网络输入中断，或与默认的不进行远程回显的NVT说明的主机来说，此规则的代价是高昂的。因此，在源点缓存一些数据是有理由的。一些系统在每个输入行未采用一些操作（即使是行打印机或打卡机也经常采用这种方法），这样可以在每行未开始发送。在另一方面，用户或者进程可以有时发觉提供在行未不中断的数据是有用的而且是必须的；因此，也应该在实现在本地能够识别这种信号并把这些数据立刻发送的方法和机制。当一个进程已经完成将数据发送到对方的显示设备而且也没有缓存的输入数据时时，进程必须发送TELNET Go Ahead (GA)命令。
这个规则并不是要求 TELNET GA命令必须由双方终端发送，因为服务器主机通常不要求特定的信号来继续进程。但是，此命令的设计可以帮助用户的本地主机操作一个物理上半双工的终端，它如果IBM2741一样拥有可锁定的键盘。对此种类型终端的描述有助于解释GA命令的正确使用。终端和计算机的连接总是在计算机或用户的控制之下。任何一方都不能够隐式地从另一方获得控制权；控制权必须显式地从一方转移到另一方。
在终端一方，设置硬件在每一行结束时放弃控制权（例如，当用户按下回车键时）。当这种情况发生时，本地计算机处理输入数据，决定是否输出，如果不需要，将控制权回送给终端。如果需要产生输出，计算机将保有控制权直到输出数据发送完毕。在网络上使用这种终端的困难是显而易见的。“本地”计算机不知道在读到行未符号时是否应该继续保持控制权；这个问题的决定权在远地处理此数据的计算机。因此，TELNET GA命令提供了一种机制让远程计算机能够通知本地计算机，让它将控制权转交给用户终端。在用户需要控制权时，此信号应该也只能在此时发送。注意：过早地发送GA命令会使输出数据阻塞，因为用户可以假定传送系统暂停，因此不能将一行结束。当然，前述内容不能够用于用户到服务器方面的通信方面。在这个方面，GA命令可以在任何时候发送，可以根本不用发送。同样，如果TELNET连接被用于进程到进程的通信，也不需要发送GA命令。
最后，对于终端到终端的通信，可以在两端都需要GA命令，也可以在一端，也可以两端都需要。如果主机希望支持终端到终端的通信主机应该提供一种让用户自由发送GA命令的方法；然而，对于一个TELNET进程而言，这并不是必须的。注意：TELNET模式的对称性要求在概念上，两端中的一端至少是一个NVT。控制函数的标准表示 如要本文的介绍中所说的，TELNET协议的目的是提供一种网络上面向终端进程和终端设备的标准接口。
这种类型互连的先前的经验告诉我们，在许多主机上已经实现了类似的功能，但它们的实现方法却差别很大。对于接触这些系统的用户而言，这些差别将是令人头痛的。因此，TELNET定义了以下功能的五种标准表示。这种标准表示有一定的标准的意义，但这也不是必须的（例外是中断处理函功能要其它使用TELNET的协议执行）；这也就是说，系统不提供给本地用户的功能也不可以不提供给远程用户，它可以将标准表示作为非操作的功能。
在另一方面，给本地用户提供此功能的系统必须也向传送此功能标准表示的远程用户提供此功能。
中断处理（IP）一些系统提供可以暂停，中断，放弃或终止用户进程操作的功能。当用户确定它的进程处于不可结束的循环中，或不经意地激活了一个进程时经常使用此功能。IP是使用此功能的标准表示。实现者应该注意的是：使用TELNET的其它协议可能也需要IP，因此，如果需要支持其它协议就应该实现IP。放弃输出 (AO) 许多系统提供此功能，它允许产生输出的进程到达类似操作结束的点，而不将输出发送到用户的终端。更深一层的，此功能通常清除已产生的所有输出，而不显示到用户的终端上。AO是使用此功能的标准表示。
尊重作者 转载请注明出处52mud.com
