Secction2Part3CS模型.pptVIP

第18章 C/S模型;18.1 基本模型 最简单的客户——服务器模型如下图所示： 客户端：通信的发起者 服务器端：通信呼叫请求等待者 ;18.1.1 面向连接与无连接 1、面向连接的TCP与无连接的UDP差别； 2、采用UDP还是TCP的一般原则： （1）C/S之间交互简单，宜采用UDP，如daytime和echo； （2）相比数据可靠性，对传输时间更敏感的网络应用宜采用UDP，如音频视频系统； （3）组播或广播系统必须要用UDP。 注意：采用UDP模式，必须设计良好的能够保证数据可靠传输的应用层协议，因此必须在应用层自行解决确认、超时重传和流量控制。;18.1.2 并发和迭代 1、迭代服务器： 一次只能为一个客户服务，提供简单服务，不适用于复杂服务的提供，一般采用UDP。 2、并发服务器： 同时接受多个客户连接，较好支持复杂任务，一般采用TCP。;18.2 Winsock I/O方法 如何在Windows套接口应用程序中对I/O操作进行管理？Winsock分别提供了“套接口模式”和“套接口I/O模型”，可以对一个套接口行为加以控制。其中，套接口模式用于决定在随一个套接口调用时，那些Winsock函数的行为。而另一方面，套接口模型描述了一个应用程序如何对套接口上进行的I/O进行管理及处理。要注意的是，“套接口I/O模型”与“套接口模式”是无关的。套接口模型的出现，正是为了解决套接口模式存在的某些限制。 ; Winsock提供两种套接口模式：阻塞和非阻塞模式。Winsock同时还提供了一些I/O模型，便于应用程序通过“异步”方式，一次对一个或多个套接字上进行的通信加以管理。这些模型包括select（选择）、WSAAsyncSelect（异步选择）、WSAEventSelect（事件选择）、Overlapped I/O（重叠式I/O）以及Completion port（完成端口）等。 所有Windows平台都支持套接口以阻塞或非阻塞方式工作。然而，并非每种平台都支持每一种I/O模型。在Windows CE 中，仅提供了一个I/O模型。Windows 2000及以上各版本，则每种I/O模型都支持。;18.2.1 套接口模式 Windows套接口在两种模式下执行I/O操作：阻塞和非阻塞。在阻塞模式下，在I/O操作完成前，执行操作的Winsock函数（如send和recv）会一直等候下去，不会立即返回程序??将控制权交还给程序）。而在非阻塞模式下，Winsock函数无论如何都会立即返回。在Windows CE（安装Winsock 1）平台上运行的应用程序仅支持极少的I/O模型，所以我们必须采取一些适当的步骤，让阻塞和非阻塞套接口能够满足各种场合的要求。;1、阻塞模式 对于处在阻塞模式的套接口，我们必须多加留意，因为在一个锁定套接字上调用任何一个Winsock API函数，都会产生相同的后果—耗费或长或短的时间“等待”。大多数Winsock应用都是遵照一种“生产者－消费者”模型来编制的。在这种模型中，应用程序需要读取（或写入）指定数量的字节，然后以它为基础执行一些计算。下面的代码片断便是一个典型的例子。;Section 2,Chapter 3; 上述代码的问题在于：假如没有数据处于“待决”状态，那么recv函数可能永远都无法返回。 如何避免这一情况呢？在此，我们的目标是防止由于数据的缺乏（这可能是网络出了故障，也可能是客户机出了问题），造成应用程序完全陷于“凝固”状态，同时不必连续性地检视系统网络缓冲！ ; 为达此目的，一个办法是将应用程序划分为一个读线程，以及一个计算线程。两个线程都共享同一个数据缓冲区。对这个缓冲区的访问需要受到一定的限制，这是用一个同步对象来实现的，比如一个事件或者Mutex（互斥体）。“读线程”的职责是从网络连续读入数据，并将其置入共享缓冲区内。 读线程将计算线程开始工作至少需要的数据量拿到手后，便会触发一个事件，通知计算线程可以开始干活了！随后，计算线程从缓冲区取走（删除）一个数据块，然后进行要求的计算。 ;Section 2,Chapter 3; 对阻塞套接口来说，它的主要缺点是应用程序很难同时通过多个建好连接的套接口通信。使用前述的办法，可对应用程序进行修改，令其为连好的每个套接字都分配一个读线程，以及一个数据处理线程。尽管这仍然会增大一些开销，但的确是一种可行的方案。唯一的缺点便是扩展性极差，以后想同时处理大量套接口时，会很难下手。;2、 非阻塞模式 非阻塞方式套接口可以很好地处理上述情况，因此其功能强大，编程灵活，尤其是非阻塞方式