Windows网络编程 2nd Edition 第二章 Winsock的设计 Notes
1. System Architecture. 首先看附件1中的架构图。在ws2_32.dll下，分成了很多层，各自管各自的事情。在Winsock中，所谓的Provider指的是针对不同的协议 实现的包装，比如TCP有TCP的Provider，根据我们的winsock代码在创建socket的时候指定需要的协议来选择不同的Provider 为我们的程序提供服务。在图中可以看到，Provider又分成base和layered两种。我的理解是base provider就是最基本的针对协议的实现，如上面所说；layered provider根据书中的描述，是架构在ws2_32.dll之下，base provider之上的一个东西，他能拦截和操纵所有的socket操作。详情参考第12章
2. 在Provider往下的就是kernel层的东西了，在最低层当然就是协议的具体实现了，比如TCP/IP等，但是这些协议的实现，没有一个类似 Socket的调用接口，取而代之的是TDI接口（Transport Driver Interface），这样做是为了更好的和上层应用解耦。既然这样，就必然有个东西出来扮演Coordinator的角色，这就是在底层驱动实现上面一 层的Windows Socket Kernel Mode Driver（AFD.SYS），这个驱动负责connection和buffer这些东西的维护，同时提供一个socket的接口给上层应用。同时，他 也负责和TDI接口的底层实现通讯，对话。
3. 协议特性。本节其实是根据一定的标准对网络通信的协议进行了一个分类和阐述。本节不具体介绍TCP，UDP这些东西，而是根据协议的特性对协议做了一个分类。
(1) Message-Oriented
参考 附件2 。所谓消息类型的网络通讯最大的特点就是"preserving message boundaries"，从附件2的图中也可以看出来。分别发送128, 64, 32的数据，在对方收到的时候也是收到这样的三个包。UDP就是这样类似的协议，而且前面一张还提到过AppleTalk，基于消息的协议，而且还支持 Partial Message。
(2) Stream-Oriented
参考 附件3 。 流式和消息类型最大的不同就是数据不会被保留边界。也就是说，在接受的时候，我们请求了多少数据，它就返回尽可能多的数据，数据和数据之间没有边界和分 割，在发送方来看也是一样。在流式协议上，有数据不是立刻就发送，而是当buffer到了一定程度之后，或是过了多长时间之后，才把数据一次性全发出去， 在接受方面，也是一样，接受会返回尽可能多的数据。所以在附件3的图上可以看出，发送的时候后两次的数据合并在一起发送了，接受则是一次性把所有数据全都 接受过来了。流式协议典型的就是TCP，用来传输数据不错。但是在大量传输小数据的场合，流式协议显然有先天的问题，因为每次的数据都要做Error check，带来了额外的开销。
(3) Pseudo Stream
顾名思义就可以知道，这是基于消息的传输方式，但是冠以了流的特性。将附件2图中的左半部分和附件3中图的右半部分合并在一起就是这种协议的特性了。发送还是独立发送单独的message，收的时候可以一次性全收过来。
(4) Connection-Oriented and Connectionless, Reliability and Ordering, Grace Close 这三部分的内容第一章已经讲过了，不再赘述
(5) Broadcast Data.
广播数据只适用于connectionless的协议，因为网络上的每台机器都将收到数据。广播的效率是低的，而且每台机器都要去check数据，导致了额外的开销。
(6) Multicast Data
多播数据在视频会议的时候特别有用，就是一个源可以将数据同时发给多个人，但不是广播。在基于IP的协议中，多播是对广播的一个修改。首先在IP 地址段中就有专门用于multicast的IP地址，然后当多播发生前，每个希望发送或收到多播数据的进程/程序需要申请加入到绑定在特定多播IP地址的 一个多播group中，然后发往这个group的消息，每个加入多播group的程序就都能收到了。其实在每台加入多播group的机器上，在加入多播 group的时候，就在网卡上设定了一个filter，从而实现了上述的功能。多播在第九章有专门的描述。
(7) Quality of Server (QoS)
这个东西也很有意思。QoS是一种应用能力，他能申请将固定的一部分网络带宽用于特定的用途。实际的例子就是视频点播。在以往，视频点播需要先缓 冲一部分数据，当网络数据达不到要求的时候，就先播放缓冲中的数据，同时尽量的去填充缓冲。当然这是在internet上，如果在特定的一个网络内，我们 就可以使用QoS，根据视频点播需要的网络带宽，将网络的一部分带宽保留起来就给我们做视频点播用，那么这样一来，理论上来说，我们做视频点播的时候根本 就不需要什么缓冲了。第十章有对QoS的详细描述。
(8) Partial Messages
第一章已经讲过了，使用Partial Message的好处就在于他能返回一部分数据。在不支持Partial Message的协议上，当一部分数据到达后，是不能取出来给应用程序的，只有当全部数据到达后，才能给应用程序取出，那么，如果网络发生了一些问题或由 于某些原因，剩余的数据一直不能到达，那么，对于不支持Partial Message的协议来说，就会在timeout的时候将已经收到的部分数据丢弃，应用程序从而收不到任何的数据。
(9) Routing Considerations
NetBEUI是WINSOCK目前唯一支持的不使用路由的协议。
4. Winsock Catalog。本节介绍了WSAEnumProtocols函数，用这个函数可以列出winsock支持的所有协议和该协议的具体信息（比如支不支持 data ordering，最大的transmission size等）。在这个基础上，对创建socket的函数做了一个深入，我们在使用winsock 1.1的socket的函数的时候，必须指定协议特性和协议：
SOCKET s;
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
比如我们指定流式，使用TCP协议。
但是如果有一些provider共享相同的协议特性和协议的话，也就是说有多个provider都实现了同一个协议，那么socket函数就无法 实现这样的功能。比如RSVP provider，他能在TCP和UDP上提供QOS。这样的provider我们就无法用socket函数构建出来。（其实更多时候我们创建的 socket就是一个provider，这是winsock根据我们创建socket的时候给定的参数给我们选定的provider）。此时 WSASocket函数就派上用处了。
详细信息看本节原文吧，老实说，本节没怎么看明白，以后看到具体章节的时候再回头来看，可能会有收获。
1. System Architecture. 首先看附件1中的架构图。在ws2_32.dll下，分成了很多层，各自管各自的事情。在Winsock中，所谓的Provider指的是针对不同的协议 实现的包装，比如TCP有TCP的Provider，根据我们的winsock代码在创建socket的时候指定需要的协议来选择不同的Provider 为我们的程序提供服务。在图中可以看到，Provider又分成base和layered两种。我的理解是base provider就是最基本的针对协议的实现，如上面所说；layered provider根据书中的描述，是架构在ws2_32.dll之下，base provider之上的一个东西，他能拦截和操纵所有的socket操作。详情参考第12章
2. 在Provider往下的就是kernel层的东西了，在最低层当然就是协议的具体实现了，比如TCP/IP等，但是这些协议的实现，没有一个类似 Socket的调用接口，取而代之的是TDI接口（Transport Driver Interface），这样做是为了更好的和上层应用解耦。既然这样，就必然有个东西出来扮演Coordinator的角色，这就是在底层驱动实现上面一 层的Windows Socket Kernel Mode Driver（AFD.SYS），这个驱动负责connection和buffer这些东西的维护，同时提供一个socket的接口给上层应用。同时，他 也负责和TDI接口的底层实现通讯，对话。
3. 协议特性。本节其实是根据一定的标准对网络通信的协议进行了一个分类和阐述。本节不具体介绍TCP，UDP这些东西，而是根据协议的特性对协议做了一个分类。
(1) Message-Oriented
参考 附件2 。所谓消息类型的网络通讯最大的特点就是"preserving message boundaries"，从附件2的图中也可以看出来。分别发送128, 64, 32的数据，在对方收到的时候也是收到这样的三个包。UDP就是这样类似的协议，而且前面一张还提到过AppleTalk，基于消息的协议，而且还支持 Partial Message。
(2) Stream-Oriented
参考 附件3 。 流式和消息类型最大的不同就是数据不会被保留边界。也就是说，在接受的时候，我们请求了多少数据，它就返回尽可能多的数据，数据和数据之间没有边界和分 割，在发送方来看也是一样。在流式协议上，有数据不是立刻就发送，而是当buffer到了一定程度之后，或是过了多长时间之后，才把数据一次性全发出去， 在接受方面，也是一样，接受会返回尽可能多的数据。所以在附件3的图上可以看出，发送的时候后两次的数据合并在一起发送了，接受则是一次性把所有数据全都 接受过来了。流式协议典型的就是TCP，用来传输数据不错。但是在大量传输小数据的场合，流式协议显然有先天的问题，因为每次的数据都要做Error check，带来了额外的开销。
(3) Pseudo Stream
顾名思义就可以知道，这是基于消息的传输方式，但是冠以了流的特性。将附件2图中的左半部分和附件3中图的右半部分合并在一起就是这种协议的特性了。发送还是独立发送单独的message，收的时候可以一次性全收过来。
(4) Connection-Oriented and Connectionless, Reliability and Ordering, Grace Close 这三部分的内容第一章已经讲过了，不再赘述
(5) Broadcast Data.
广播数据只适用于connectionless的协议，因为网络上的每台机器都将收到数据。广播的效率是低的，而且每台机器都要去check数据，导致了额外的开销。
(6) Multicast Data
多播数据在视频会议的时候特别有用，就是一个源可以将数据同时发给多个人，但不是广播。在基于IP的协议中，多播是对广播的一个修改。首先在IP 地址段中就有专门用于multicast的IP地址，然后当多播发生前，每个希望发送或收到多播数据的进程/程序需要申请加入到绑定在特定多播IP地址的 一个多播group中，然后发往这个group的消息，每个加入多播group的程序就都能收到了。其实在每台加入多播group的机器上，在加入多播 group的时候，就在网卡上设定了一个filter，从而实现了上述的功能。多播在第九章有专门的描述。
(7) Quality of Server (QoS)
这个东西也很有意思。QoS是一种应用能力，他能申请将固定的一部分网络带宽用于特定的用途。实际的例子就是视频点播。在以往，视频点播需要先缓 冲一部分数据，当网络数据达不到要求的时候，就先播放缓冲中的数据，同时尽量的去填充缓冲。当然这是在internet上，如果在特定的一个网络内，我们 就可以使用QoS，根据视频点播需要的网络带宽，将网络的一部分带宽保留起来就给我们做视频点播用，那么这样一来，理论上来说，我们做视频点播的时候根本 就不需要什么缓冲了。第十章有对QoS的详细描述。
(8) Partial Messages
第一章已经讲过了，使用Partial Message的好处就在于他能返回一部分数据。在不支持Partial Message的协议上，当一部分数据到达后，是不能取出来给应用程序的，只有当全部数据到达后，才能给应用程序取出，那么，如果网络发生了一些问题或由 于某些原因，剩余的数据一直不能到达，那么，对于不支持Partial Message的协议来说，就会在timeout的时候将已经收到的部分数据丢弃，应用程序从而收不到任何的数据。
(9) Routing Considerations
NetBEUI是WINSOCK目前唯一支持的不使用路由的协议。
4. Winsock Catalog。本节介绍了WSAEnumProtocols函数，用这个函数可以列出winsock支持的所有协议和该协议的具体信息（比如支不支持 data ordering，最大的transmission size等）。在这个基础上，对创建socket的函数做了一个深入，我们在使用winsock 1.1的socket的函数的时候，必须指定协议特性和协议：
SOCKET s;
s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);
比如我们指定流式，使用TCP协议。
但是如果有一些provider共享相同的协议特性和协议的话，也就是说有多个provider都实现了同一个协议，那么socket函数就无法 实现这样的功能。比如RSVP provider，他能在TCP和UDP上提供QOS。这样的provider我们就无法用socket函数构建出来。（其实更多时候我们创建的 socket就是一个provider，这是winsock根据我们创建socket的时候给定的参数给我们选定的provider）。此时 WSASocket函数就派上用处了。
详细信息看本节原文吧，老实说，本节没怎么看明白，以后看到具体章节的时候再回头来看，可能会有收获。
