XXXXXXX

IBM 公司于94年4月推出的TCP/IP for DOS V2.1.1提供的开发软件包Programmer's Tool Kit不仅带有DOS下网络编程接口，而且提供了Windows下网络异步通信接口WINSOCK。

    Socket是BSD UNIX提供的网络应用编程接口，它采用客户－服务器的通讯机制，使网络客户方和服务器方通过Socket实现网络之间的连接和数据交换。Socket提供了一系列的系统调用，使用这些系统调用可以实现TCP, UDP,ICMP和IP等多种网络协议之间的通讯。

    Socket有三种主要类型：stream sockets, datagram sockets 和raw sockets 。 Stream socket接口定义了一种可靠的面向连接的服务，它实现了无差错无重复的顺序数据传输。它通过内置的流量控制解决了数据的拥塞，应用程序可以发送任意长度的数据，将数据当作字节流。Datagram socket接口定义了一种无连接的服务，数据通过相互独立的包进行传输，包的传输是无序的，并且不保证是否出错、丢失和重复。包长度是有限的（隐含长度为8,192字节，最大长度可设为32,768字节）。Raw socket接口允许对低层协议如IP和ICMP的直接存取，它主要用于新的网络协议实现的测试等。

图2-1 面向连接的协议实现的Socket调用

    从图2-1中我们可以看出，客户和服务器的关系不是对称的，服务器首先启动，然后在某一时间启动客户与服务器建立连接。服务器和客户开始都必须用调用socket()建立一个套接字（socket），然后服务器调用bind()将套接字与一个本地网络地址捆扎在一起，再用调用listen()使套接字处于一种被动的准备接收状态，同时规定它的请求队列长度，之后服务器就可以调用accept()来接收连接了。客户在建立套接字之后，便可以通过调用connect()和服务器建立连接。连接建立后，客户和服务器之间就可以通过连接发送和接收数据（调用read()和write()）。最后，待数据传送结束，双方调用close()关闭套接字^[7]。

    WINSOCK对Socket的扩充。WINSOCK对BSD Socket的扩充主要是在基于消息、对网络事件的异步存取接口上。BSD Socket支持阻塞（blocking）和非阻塞（non_blocking）两种工作方式。在阻塞方式下工作，connect()、accept()、read()和recv()等调用在执行时都处于阻塞状态直到它成功或出错返回。在非阻塞方式下工作，这些调用是立即返回的，但是它们是否完成得靠查询才能知道。对于Windows这种非抢先多任务操作系统来说，这两种工作方式都是很难以接受的，为此，WINSOCK在尽量与BSD Socket保持一致外，又对它作了必要的扩充。90年代初，由Microsoft联合了其他几家公司共同制定了一套WINDOWS下的网络编程接口，即Windows Sockets规范，它不是一种网络协议,而是一套开放的、支持多种协议的Windows下的网络编程接口。现在的Winsock已经基本上实现了与协议无关，你可以使用Winsock来调用多种协议的功能，但较常使用的是TCP/IP协议。Socket实际在计算机中提供了一个通信端口，可以通过这个端口与任何一个具有Socket接口的计算机通信。应用程序在网络上传输，接收的信息都通过这个Socket接口来实现^[8,9,10,11]。

    LSP全称Winsock Layered Service Provider  ，Winsock 2 LSPs 都是以标准的 Windows DLLs 实现的，这些 DLLs 只有一个导出的入口函数，WSPStartup。ws2_32.dll 和 upper chain layered provider 中所有其它的 transport SPI 都是通过 LSP 的 dispatch table 来访问的，即 WSPStartup 函数中的参数 lpProcTable。我们通过 WSPStartup 的参数 UpcallTable 来将 ws2_32.dll 的 upcall dispatch table 送给 LSP。结构体 WSPPROC_TABLE定义了 LSP 必须实现的函数以及那些函数的入口点要填入 WSPStartup 的 lpProcTable 参数。

    尽管看上去 LSP 似乎要为各种情况来实现一大堆的函数，但可以直接调用协议链中下一个相应的 function service provider。结构体 WSPUPCALLTABLE定义了 ws2_32.dll 的 upcall 函数们以供 LSP 调用。这些 upcall 函数们都是从 WSPStartup 的 UpcallTable 参数中得到的。WSPUPCALLTABLE 是一个定长的结构体。如果要往 ws2_32.dll 中添加新的 upcall 函数，就需要在 LSP 的 WSPStartup 调用 GetProcAddress 来取得指向新的 upcall 函数的指针。当前只存在一个这样的函数——WPUCompleteOverlappedResult。LSPs 和 base providers 都被串了起来形成了一个协议链。WSAPROTOCOL_INFOW 结构体指的就是整个的协议链。它描述了 layered providers  的连接顺序。实现 LSP 的 DLL 要么由另一个 LSP 加载，要么直接由 ws2_32.dll 加载，这要看此 LSP 在协议链中的位置。如果 LSP 没处在协议链的顶端，则该 LSP 由上一层的 LSP 加载，否则就由 ws2_ 32.dll 加载（在 layered sample 中，低一层的 chain provider 是在第一个 WSPSocket 调用中加载的）。加载 LSP 后，必须调用该 LSP 的 WSPStartup。最终从 ws2_32.dll 中取得的 UpcallTable 必须向下传递到该 LSP，并且此时必须取得该 LSP 的 lpProcTable。

       当 LSP 调用了协议链中的低一层的 provider 的 WSPStartup 时，如果低一层的 provider 又是一个 layered provider，则此链的 WSAPROTOCOL_INFOW 结构体必须传递给 WSPStartup 调用。当低一层是一个 base protocol（链的结尾）时，此链的 WSAPROTOCOL_INFOW 结构体就不再向下传递，而此时必须取得 base provider 的 WSAPROTOCOL_ INFOW 结构体并将其传递给 base provider 的 WSPStartup 调用。因此，此种迹象表明 base provider 并不在协议链中。当专门函数（如 WSPStringToAddress 和 WSPAddressToString）向下一环节传递 WSAPROTOCOL_INFOW 结构体时，情形也是一样的