20CN网络安全小组论坛 - 编程破解 - Windows Sockets 规范及应用(第二章使用Windows Sockets 1.1编程)

论坛: 编程破解标题: Windows Sockets 规范及应用(第二章使用Windows Sockets 1.1编程)

作者: xiaoxingchi [xiaoxingchi]

论坛用户

第二章使用Windows Sockets 1.1编程
在这一章，我们将介绍如何使用Windows Sockets 1.1编程，并讨论了使用Windows Sockets 1.1编程的一些细节问题。本章的讨论均是基于Windows Sockets 1.1规范的，在某些方面可能会和第六、七章对Windows Sockets 2的讨论不一致，请读者注意这一区别。

2.1 Windows Sockets协议栈安装检查
任何一个与Windows Sockets Import Library联接的应用程序只需简单地调用WSAStartup()函数便可检测系统中有没有一个或多个Windows Sockets实现。而对于一个稍微聪明一些的应用程序来说，它会检查PATH环境变量来寻找有没有Windows Sockets实现的实例（Windows Sockets.DLL）。对于每一个实例，应用程序可以发出一个LoadLibrary()调用并且用WSAStartup()函数来得到这个实现的具体数据。
这一版本的Windows Sockets规范并没有试图明确地讨论多个并发的Windows Sockets实现共同工作的情况。但这个规范中没有任何规定可以被解释成是限制多个Windows Sockets DLL同时存在并且被一个或者多个应用程序同时调用的。

2.2 套接口

2.2.1 基本概念
通讯的基石是套接口，一个套接口是通讯的一端。在这一端上你可以找到与其对应的一个名字。一个正在被使用的套接口都有它的类型和与其相关的进程。套接口存在于通讯域中。通讯域是为了处理一般的线程通过套接口通讯而引进的一种抽象概念。套接口通常和同一个域中的套接口交换数据（数据交换也可能穿越域的界限，但这时一定要执行某种解释程序）。Windows Sockets规范支持单一的通讯域，即Internet域。各种进程使用这个域互相之间用Internet协议族来进行通讯（Windows Sockets 1.1以上的版本支持其他的域，例如Windows Sockets 2）。
套接口可以根据通讯性质分类；这种性质对于用户是可见的。应用程序一般仅在同一类的套接口间通讯。不过只要底层的通讯协议允许，不同类型的套接口间也照样可以通讯。
用户目前可以使用两种套接口，即流套接口和数据报套接口。流套接口提供了双向的，有序的，无重复并且无记录边界的数据流服务。数据报套接口支持双向的数据流，但并不保证是可靠，有序，无重复的。也就是说，一个从数据报套接口接收信息的进程有可能发现信息重复了，或者和发出时的顺序不同。数据报套接口的一个重要特点是它保留了记录边界。对于这一特点，数据报套接口采用了与现在许多包交换网络（例如以太网）非常类似的模型。

2.2.2 客户机/服务器模型
一个在建立分布式应用时最常用的范例便是客户机/服务器模型。在这种方案中客户应用程序向服务器程序请求服务。这种方式隐含了在建立客户机/服务器间通讯时的非对称性。客户机/服务器模型工作时要求有一套为客户机和服务器所共识的惯例来保证服务能够被提供（或被接受）。这一套惯例包含了一套协议。它必须在通讯的两头都被实现。根据不同的实际情况，协议可能是对称的或是非对称的。在对称的协议中，每一方都有可能扮演主从角色；在非对称协议中，一方被不可改变地认为是主机，而另一方则是从机。一个对称协议的例子是Internet中用于终端仿真的TELNET。而非对称协议的例子是Internet中的FTP。无论具体的协议是对称的或是非对称的，当服务被提供时必然存在“客户进程”和“服务进程”。
一个服务程序通常在一个众所周知的地址监听对服务的请求，也就是说，服务进程一直处于休眠状态，直到一个客户对这个服务的地址提出了连接请求。在这个时刻，服务程序被“惊醒”并且为客户提供服务－对客户的请求作出适当的反应。这一请求/相应的过程可以简单的用图2-1表示。虽然基于连接的服务是设计客户机/服务器应用程序时的标准，但有些服务也是可以通过数据报套接口提供的。

2.2.3 带外数据
注意：以下对于带外数据（也称为TCP紧急数据）的讨论，都是基于BSD模型而言的。用户和实现者必须注意，目前有两种互相矛盾的关于RFC 793的解释，也就是在这基础上，带外数据这一概念才被引入的。而且BSD对于带外数据的实现并没有符合RFC 1122定下的主机的要求，为了避免互操作时的问题，应用程序开发者最好不要使用带外数据，除非是与某一既成事实的服务互操作时所必须的。Windows Sockets提供者也必须提供他们的产品对于带外数据实现的语义的文挡（采用BSD方式或者是RFC 1122方式）。规定一个特殊的带外数据语义集已经超出了Windows Sockets规范的讨论范围。
流套接口的抽象中包括了带外数据这一概念，带外数据是相连的每一对流套接口间一个逻辑上独立的传输通道。带外数据是独立于普通数据传送给用户的，这一抽象要求带外数据设备必须支持每一时刻至少一个带外数据消息被可靠地传送。这一消息可能包含至少一个字节；并且在任何时刻仅有一个带外数据信息等候发送。对于仅支持带内数据的通讯协议来说（例如紧急数据是与普通数据在同一序列中发送的），系统通常把紧急数据从普通数据中分离出来单独存放。这就允许用户可以在顺序接收紧急数据和非顺序接收紧急数据之间作出选择（非顺序接收时可以省去缓存重叠数据的麻烦）。在这种情况下，用户也可以“偷看一眼”紧急数据。
某一个应用程序也可能喜欢线内处理紧急数据，即把其作为普通数据流的一部分。这可以靠设置套接口选项中的SO_OOBINLINE来实现（参见5.1.21节，setsockopt()）。在这种情况下，应用程序可能希望确定未读数据中的哪一些是“紧急”的（“紧急”这一术语通常应用于线内带外数据）。为了达到这个目的，在Windows Sockets的实现中就要在数据流保留一个逻辑记号来指出带外数据从哪一点开始发送，一个应用程序可以使用SIOCATMARK ioctlsocket()命令（参见5.1.12节）来确定在记号之前是否还有未读入的数据。应用程序可以使用这一记号与其对方进行重新同步。
WSAAsyncSelect()函数可以用于处理对带外数据到来的通知。

2.2.4 广播
数据报套接口可以用来向许多系统支持的网络发送广播数据包。要实现这种功能，网络本身必须支持广播功能，因为系统软件并不提供对广播功能的任何模拟。广播信息将会给网络造成极重的负担，因为它们要求网络上的每台主机都为它们服务，所以发送广播数据包的能力被限制于那些用显式标记了允许广播的套接口中。广播通常是为了如下两个原因而使用的：1. 一个应用程序希望在本地网络中找到一个资源，而应用程序对该资源的地址又没有任何先验的知识。2. 一些重要的功能，例如路由要求把它们的信息发送给所有可以找到的邻机。
被广播信息的目的地址取决于这一信息将在何种网络上广播。Internet域中支持一个速记地址用于广播－INADDR_BROADCAST。由于使用广播以前必须捆绑一个数据报套接口，所以所有收到的广播消息都带有发送者的地址和端口。
某些类型的网络支持多种广播的概念。例如IEEE802.5令牌环结构便支持链接层广播指示，它用来控制广播数据是否通过桥接器发送。Windows Sockets规范没有提供任何机制用来判断某个应用程序是基于何种网络之上的，而且也没有任何办法来控制广播的语义。

2.3 字节顺序
Intel处理器的字节顺序是和DEC VAX处理器的字节顺序一致的。因此它与68000型处理器以及Internet的顺序是不同的，所以用户在使用时要特别小心以保证正确的顺序。
任何从Windows Sockets函数对IP地址和端口号的引用和传送给Windows Sockets函数的IP地址和端口号均是按照网络顺序组织的，这也包括了sockaddr_in结构这一数据类型中的IP地址域和端口域（但不包括sin_family域）。
考虑到一个应用程序通常用与“时间”服务对应的端口来和服务器连接，而服务器提供某种机制来通知用户使用另一端口。因此getservbyname()函数返回的端口号已经是网络顺序了，可以直接用来组成一个地址，而不需要进行转换。然而如果用户输入一个数，而且指定使用这一端口号，应用程序则必须在使用它建立地址以前，把它从主机顺序转换成网络顺序（使用htons()函数）。相应地，如果应用程序希望显示包含于某一地址中的端口号（例如从getpeername()函数中返回的），这一端口号就必须在被显示前从网络顺序转换到主机顺序（使用ntohs()函数）。
由于Intel处理器和Internet的字节顺序是不同的，上述的转换是无法避免的，应用程序的编写者应该使用作为Windows Sockets API一部分的标准的转换函数，而不要使用自己的转换函数代码。因为将来的Windows Sockets实现有可能在主机字节顺序与网络字节顺序相同的机器上运行。因此只有使用标准的转换函数的应用程序是可移植的。

2.4 套接口属性选项
Windows Sockets规范支持的套接口属性选项都列在对setsockopt()函数和getsockopt()函数的叙述中。任何一个Windows Sockets实现必须能够识别所有这些属性选项，并且对每一个属性选项都返回合理的数值。每一个属性选项的缺省值列在下表中：选项类型含义缺省值注意事项

SO_ACCEPTCON BOOL 套接口正在监听。 FALSE

SO_BROADCAST BOOL 套接口被设置为可以 FALSE
发送广播数据。

SO_DEBUG BOOL 允许Debug。 FALSE (*)

S0_DONTLINGER BOOL 如果为真，SO_LINGER TRUE
选项被禁止。

SO_DONTROUTE BOOL 路由被禁止。 FALSE (*)

SO_ERROR int 得到并且清除错误状态。 0

SO_KEEPALIVE BOOL 活跃信息正在被发送。 FALSE

SO_LINGER struct 返回目前的linger信息。 l_onoff
linger 为0
FAR *

SO_OOBINLINE BOOL 带外数据正在普通数据流 FALSE
中被接收。

SO_RCVBUF int 接收缓冲区大小。决定于实现 (*)

SO_REUSEADDR BOOL 该套接口捆绑的地址 FALSE
是否可被其他人使用。

SO_SNDBUF int 发送缓冲区大小。决定于实现 (*)

SO_TYPE int 套接口类型（如和套接口被
SOCK_STREAM）。创建时一致

TCP_NODELAY BOOL 禁止采用Nagle 决定于实现
进行合并传送。

(*) Windows Sockets实现有可能在用户调用setsockopt()函数时忽略这些属性，并且在用户调用getsockopt()函数时返回一个没有变化的值。或者它可能在setsockopt()时接受某个值，并且在getsockopt()时返回相应的数值，但事实上并没有在任何地方使用它。

2.5 数据库文件
getXbyY()和WSAAyncGetXByY()这一类的例程是用来得到某种特殊的网络信息的。getXbyY()例程最初（在第一版的BERKELY UNIX中）是被设计成一种在文本数据库中查询信息的机制。虽然Windows Sockets实现可能用不同的方式来得到这些信息，但Windows Sockets应用程序要求通过getXbyY()或WSAAyncGetXByY()这一类例程得到的信息是一致。

2.6 与Berkeley套接口的不同
有一些很有限的地方，Windows Sockets API必须与从严格地坚持Berkeley传统风格中解放出来。通常这么做是因为在Windows环境中实现的难度。

2.6.1 套接口数据类型和错误数值
Windows Sockets规范中定义了一个新的数据类型SOCKET，这一类型的定义对于将来Windows Sockets规范的升级是必要的。例如在Windows NT中把套接口作为文件句柄来使用。这一类型的定义也保证了应用程序向Win/32环境的可移植性。因为这一类型会自动地从16位升级到32位。
在UNIX中所有句柄包括套接口句柄，都是非负的短整数，而且一些应用程序把这一假设视为真理。Windows Sockets句柄则没有这一限制，除了INVALID_SOCKET不是一个有效的套接口外，套接口可以取从0到INVALID_SOCKET-1之间的任意值。
因为SOCKET类型是unsigned，所以编译已经存在于UNIX环境中的应用程序的源代码可能会导致signed/unsigned数据类型不匹配的警告。
这还意味着，在socket()例程和accept()例程返回时，检查是否有错误发生就不应该再使用把返回值和-1比较的方法，或判断返回值是否为负（这两种方法在BSD中都是很普通，很合法的途径）。取而代之的是，一个应用程序应该使用常量INVALID_SOCKET，该常量已在WINSOCK.H中定义。
例如：
典型的BSD风格：
s = socket(...);
if (s == -1) /* of s<0 */
{...}

更优良的风格：
s = socket(...);
if (s == INVALID_SOCKET)
{...}

2.6.2 select()函数和FD_*宏
由于一个套接口不再表示了UNIX风格的小的非负的整数，select()函数在Windows Sockets API中的实现有一些变化：每一组套接口仍然用fd_set类型来代表，但是它并不是一个位掩码。整个组的套接口是用了一个套接口的数组来实现的。为了避免潜在的危险，应用程序应该坚持用FD_XXX宏来设置，初始化，清除和检查fd_set结构。

2.6.3 错误代码－errno,h_errno,WSAGetLastError()
Windows Sockets实现所设置的错误代码是无法通过errno变量得到的。另外对于getXbyY()这一类的函数，错误代码无法从h_errno变量得到。错误代码可以使用WSAGetLastError()调用得到。这一函数在5.3.11中讨论。这个函数在Windows Sockets实现中是作为WIN/32函数GetLastError()的先导函数（最终是一个别名）。这样做是为了在多线程的进程中为每一线程得到自己的错误信息提供可靠的保障。
为了保持与BSD的兼容性，应用程序可以加入以下一行代码：
#define errno WSAGetLastError()
这就保证了用全程的errno变量所写的网络程序代码在单线程环境中可以正确使用。当然，这样做有许多明显的缺点：如果一个原程序包含了一段代码对套接口和非套接口函数都用errno变量来检查错误，那么这种机制将无法工作。此外，一个应用程序不可能为errno赋一个新的值（在Windows Sockets中，WSASetLastError()函数可以做到这一点）。
例如：
典型的BSD风格：
r = recv(...);
if (r == -1 /* 但请见下文 */
&& errno == EWOULDBLOCK)
{...}

更优良的风格：
r = recv(...);
if (r == -1 /* 但请见下文 */
&& WSAGetLastError() == EWOULDBLOCK)
{...}

虽然为了兼容性原因，错误常量与4.3BSD所提供的一致；应用程序应该尽可能地使用“WSA”系列错误代码定义。例如，一个更准确的上面程序片断的版本应该是：
r = recv(...);
if (r == -1 /* 但请见下文 */
&& WSAGetLastError() == WSAEWOULDBLOCK)
{...}

2.6.4 指针
所有应用程序与Windows Sockets使用的指针都必须是FAR指针，为了方便应用程序开发者使用，Windows Sockets规范定义了数据类型LPHOSTENT。

2.6.5 重命名的函数
有两种原因Berkeley套接口中的函数必须重命名以避免与其他的API冲突：

2.6.5.1 close()和closesocket()
在Berkeley套接口中，套接口出现的形式与标准文件描述字相同，所以close()函数可以用来和关闭正规文件一样来关闭套接口。虽然在Windows Sockets API中，没有任何规定阻碍Windows Sockets实现用文件句柄来标识套接口，但是也没有任何规定要求这么做。套接口描述字并不认为是和正常文件句柄对应的,而且并不能认为文件操作，例如read()，write()和close()在应用于套接口后不能保证正确工作。套接口必须使用closesocket()例程来关闭，用close()例程来关闭套接口是不正确的，这样做的效果对于Windows Sockets规范说来也是未知的。

2.6.5.2 ioctl()和iooctlsocket()
许多C语言的运行时系统出于与Windows Sockets无关的目的使用ioctl()例程，所以Windows Sockets定义ioctlsocket()例程。它被用于实现BSD中用ioctl()和fcntl()实现的功能。

2.6.6 阻塞例程和EINPROGRESS宏
虽然Windows Sockets支持关于套接口的阻塞操作，但是这种应用是被强烈反对的.如果程序员被迫使用阻塞模式（例如一个准备移植的已有的程序），那么他应该清楚地知道Windows Sockets中阻塞操作的语义。有关细节请参见4.1.1

2.6.7 Windows Sockets支持的最大套接口数目
一个特定的Windows Sockets提供者所支持的套接口的最大数目是由实现确定的。任何一个应用程序都不应假设某个待定数目的套接口可用。这一点在4.3.15 WSAStartup()中会被重申。而且一个应用程序可以真正使用的套接口的数目和某一特定的实现所支持的数目是完全无关的。
一个Windows Sockets应用程序可以使用的套接口的最大数目是在编译时由常量FD_SETSIZE决定的。这个常量在select()函数（参见4.1.18）中被用来组建fd_set结构。在WINSOCK.H中缺省值是64。如果一个应用程序希望能够使用超过64个套接口，则编程人员必须在每一个源文件包含WINSOCK.H前定义确切的FD_SET值。有一种方法可以完成这项工作，就是在工程项目文件中的编译器选项上加入这一定义。例如在使用Microsoft C时加入-D FD_SETSIZE=128作为编译命令的一个命令行参数.要强调的是：FD_SET定义的值对Windows Sockets实现所支持的套接口的数目并无任何影响。

2.6.8 头文件
为了方便基于Berkeley套接口的已有的源代码的移植，Windows Sockets支持许多Berkeley头文件。这些Berkeley头文件被包含在WINSOCK.H中。所以一个Windows Sockets应用程序只需简单的包含WINSOCK.H就足够了（这也是一种被推荐使用的方法）。

2.6.9 API调用失败时的返回值
常量SOCKET_ERROR是被用来检查API调用失败的。虽然对这一常量的使用并不是强制性的，但这是推荐的。如下的例子表明了如何使用SOCKET_ERROR常量

典型的BSD风格：
r = recv(...);
if (r == -1 /* or r < 0 */
&& errno == EWOULDBLOCK)
{...}

更优良的风格：
r = recv(...);
if (r == SOCKET_ERROR
&& WSAGetLastError == WSAEWOULDBLOCK)
{...}

2.6.10 原始套接口
Windows Sockets规范并没有规定Windows Sockets DLL必须支持原始套接口－用SOCK_RAW打开的套接口。然而Windows Sockets规范鼓励Windows Sockets DLL提供原始套接口支持。一个Windows Sockets兼容的应用程序在希望使用原始套接口时应该试图用socket()调用（参见5.1.23节）来打开套接口。如果这么做失败了，应用程序则应该使用其他类型的套接口或向用户报告错误。 2.7 在多线程Windows版本中的Windows Sockets
Windows Sockets接口被设计成既能够在单线程的Windows版本（例如Windows 3.1）又能够在占先的多线程Windows版本（例如Windows NT）中使用，在多线程环境中，套接口接口基本上是不变的。但多线程应用程序的作者必须知道，在线程之间同步对套接口的使用是应用程序的责任，而不是Windows Sockets实现的责任。这一点在其他形式的I/O中管理，例如文件I/O中是一样的。没有对套接口调用进行同步将导致不可预测的结果。例如，如果有两个线程同时调用同一套接口进行send()，那么数据发送的先后顺序就无法保证了。
在一个线程中关闭一个未完成的阻塞的套接口将会导致另一个线程使用同一套接口的阻塞调用出错（WSAEINTER）返回，就象操作被取消一样。这也同样适用于某一个select()调用未完成时，应用程序关闭了其中的一个被选择的套接口。
在占先的多线程Windows版本中，并没有缺省的阻塞钩子函数。这是因为如果一个单一的应用程序在等待某一操作结束时并不会调用PeekMessage()或GetMessage()这些会使应用程序产生一个非占先窗口的函数。因此机器在这种情况下不会被阻塞。然而，为了向后的兼容性，在多线程Windows版本中，WSASetBlockingHook()函数也被实现了。任何使用缺省阻塞钩子的应用程序可以安装它们自己的阻塞钩子函数来覆盖缺省的阻塞钩子函数。

地主发表时间: 04/29 08:36

论坛: 编程破解