Client/Server Architecture
What is client/server architecture? It means different things to different people, depending on whom you ask as well as whether you are describing a software or a hardware system. In either case, the premise is simple: the server—a piece of hardware or software—provides a “service” that is needed by one or more clients (users of the service). Its sole purpose of existence is to wait for (client) requests, respond to those clients (provide the service), and then wait for more requests. Clients, on the other hand, contact a server for a particular request, send over any necessary data, and then wait for the server to reply, either completing the request or indicating the cause of failure. The server runs indefinitely, continually processing requests; clients make a one-time request for service, receive that service, and thus conclude their transaction. A client might make additional requests at some later time, but these are considered separate transactions. The most common notion of the client/server architecture today is illustrated in Figure 2-1, which depicts a user or client computer retrieving information from a server across the Internet. Although such a system is indeed an example of a client/server architecture, it isnrsquo;t the only one. Furthermore, client/server architecture can be applied to computer hardware as well as software.
Software Client/Server Architecture
Software servers also run on a piece of hardware but do not have dedicated peripheral devices as hardware servers do (i.e., printers, disk drives, etc.). The primary services provided by software servers include program execution, data transfer retrieval, aggregation, update, or other types of programmed or data manipulation. One of the more common software servers today is the Web server. Individuals or companies desiring to run their own Web server will get one or more computers, install the Web pages and or Web applications they wish to provide to users, and then start the Web server. The job of such a server is to accept client requests, send back Web pages to (Web) clients, that is, browsers on usersrsquo; computers, and then wait for the next client request. These servers are started with the expectation of running forever. Although they do not achieve that goal, they go for as long as possible unless stopped by some external force such as being shut down, either explicitly or catastrophically (due to hardware failure). Database servers are another kind of software server. They take client requests for either storage or retrieval, act upon that request, and then wait for more business. They are also designed to run forever. The last type of software server we will discuss are windows servers. These servers can almost be considered hardware servers. They run on a computer with an attached display, such as a monitor of some sort. Windows clients are actually programs that require a windowing environment in which to execute. These are generally considered graphical user interface (GUI) applications. If they are executed without a window server, meaning, in a text-based environment such as a DOS window or a Unix shell, they are unable to start. Once a windows server is accessible, then things are fine. Such an environment becomes even more interesting when networking comes into play. The usual display for a windows client is the server on the local computer, but it is possible in some networked windowing environments, such as the X Window system, to choose another computerrsquo;s window server as a display. In such situations, you can be running a GUI program on one computer, but have it displayed at another!
Bank Tellers as Servers
One way to imagine how client/server architecture works is to create in your mind the image of a bank teller who neither eats, sleeps, nor rests, serving one customer after another in a line that never seems to end (see Figure 2-2). The line might be long or it might be empty on occasion, but at any given moment, a customer might show up. Of course, such a teller was fantasy years ago, but automated teller machines (ATMs) seem to come close to such a model now. The teller is, of course, the server that runs in an infinite loop. Each customer is a client with a need that must be addressed. Customers arrive and are handled by the teller in a first-come-first-served manner. Once a transaction has been completed, the client goes away while the server either serves the next customer or sits and waits until one comes along. Why is all this important? The reason is that this style of execution is how client/server architecture works in a general sense. Now that you have the basic idea, letrsquo;s adapt it to network programming, which follows the software client/server architecture model.
Client/Server Network Programming
Before a server can respond to client requests, some preliminary setup procedures must be performed to prepare it for the work that lies ahead. A communication endpoint is created which allows a server to listen for requests. One can liken our server to a company receptionist or switchboard operator who answers calls on the main corporate line. Once the phone number and equipment are installed and the operator arrives, theservice can begin.
This process is the same in the networked world—once a communication endpoint has been established, our listening server can now enter its infinite loop, waiting for clients to connect, and responding to requests. Of course, to keep our corporate phone receptionist busy, we must not forget to put that phone number on company letterhead, in advertisements, or some sort of press release; otherwise, no one will ever call! Similarly, potential clients must be made aware that this server exists to handle their needs—otherwise, the server will never get a single request. Imagine creating a brand new Web site. It
全文共17106字，剩余内容已隐藏，支付完成后下载完整资料
客户端/服务器架构
什么是客户端/服务器架构？对于不同的人来说，它意味着不同的东西，这取决于你问谁 以及描述的是软件还是硬件系统。在这两种情况中的任何一种下，前提都很简单：服务器就 是一系列硬件或软件，为一个或多个客户端（服务的用户）提供所需的“服务”。它存在唯一 目的就是等待客户端的请求，并响应它们（提供服务），然后等待更多请求。 另一方面，客户端因特定的请求而联系服务器，并发送必要的数据，然后等待服务器的 回应，最后完成请求或给出故障的原因。服务器无限地运行下去，并不断地处理请求；而客 户端会对服务进行一次性请求，然后接收该服务，最后结束它们之间的事务。客户端在一段 时间后可能会再次发出其他请求，但这些都被当作不同的事务。 目前最常见的客户端/服务器架构如图 2-1所示，其中描绘了一个用户或客户端计算机通过 因特网从一台服务器上检索信息。尽管这样的系统确实是一个客户端/服务器架构的例子，但它 不是唯一的情况。此外，客户端/服务器架构既可以应用于计算机硬件，也可以应用于软件。
软件客户端/服务器架构
软件服务器也运行在一块硬件之上，但是没有像硬件服务器那样的专用外围设备（如打 印机、磁盘驱动器等）。软件服务器提供的主要服务包括程序执行、数据传输检索、聚合、更 新，或其他类型的编程或数据操作。 现在一个更常见的软件服务器就是 Web 服务器。如果个人或公司想要运行自己的 Web 服务 器，那么必须拥有一台或多台计算机，在上面安装希望提供给用户的 Web 页面和 Web 应用程序， 然后启动 Web 服务器。一个这样的服务器的工作就是接受客户端请求，并向（Web）客户端（即 用户计算机上的浏览器）回送 Web 页面，然后等待下一个客户端的请求。这些服务器一旦开启， 都将可能永远运行。虽然它们并不能实现这一目标，但是它们会尽可能长时间地运行，除非受到 一些外力驱使才会停止，如显式地关闭，或灾难性地关闭（由于硬件故障）。 数据库服务器是另一种类型的软件服务器。它们接受客户端的存储或检索请求，响应请 求，然后等待更多的事务。与 Web 服务器类似，它们也是永远运行的。 我们将讨论的最后一类软件服务器就是窗体（window）服务器，几乎可以认为这些服务 器是硬件服务器。它们运行在一台附带（外接）显示设备（如显示器）的计算机上。窗体客 户端其实就是一些程序，这些程序需要一个窗口化的环境来运行。这些通常被当作图形用户 界面（GUI）应用程序。如果在没有窗体服务器的情况下执行它们，也即意味着在一个基于 文本的环境中，如 DOS 窗口或一个 UNIX shell 中，那么将无法启动它们。一旦能够访问窗 体服务器，那么一切都会正常。 在网络领域，这种环境会变得更加有趣。窗体客户端通常的显示设备就是本地计算机上 的服务器，但是在一些网络化的窗体环境（如 X Window 系统）中，也可以选择另一台计算 机的窗体服务器作为一个显示设备。在这种情况下，你就可以在一台计算机上运行一个 GUI 程序，而将它显示在另一台计算机上。
银行出纳员作为服务器
想象客户端/服务器架构如何工作的一个方法就是，在你的脑海中创建一个画面，那就是一个银行出纳员，他既不吃不睡，也不休息，服务一个又一个的排队客户，似乎永远不会结 束。这个队列可能很长，也可能空无一人，但在任何给定的某个时刻，都可能会 出现一个客户。当然，在几年前这样的出纳员完全是一种幻想，但是现在的自动取款机（ATM） 似乎比较接近这种模型。
图中的银行出纳员“永远”处于工作状态，为客户的请求提供服务。出纳员运行在一个无限循环中， 不断地接收请求并服务客户，然后返回服务或等待另一位客户。可能会有一个很长的客户队列，也可能队列 中空无一人。但在任何一种情况下，服务器的工作都永远不会结束
当然，出纳员就是一个运行在无限循环中的服务器，而每个客户就是一个客户端，每个 客户端都有一个需要解决的需求。这些客户到达银行，并由出纳以“先来先服务”的方式处 理。一旦一个事务完成，客户就会离开，而出纳员要么为下一位客户服务，要么坐下来等待， 直到下一位客户到来。 为什么所有这些都很重要呢？因为在一般意义上，这种执行风格正是客户端/服务器架构 的工作方式。既然现在你已经有了基本的概念，接下来就让我们将它应用到网络编程上，而 网络编程正是遵循客户端/服务器架构的软件模型。
客户端/服务器网络编程
在服务器响应客户端请求之前，必须进行一些初步的设置流程来为之后的工作做准备。 首先会创建一个通信端点，它能够使服务器监听请求。可以把服务器比作公司前台，或者应 答公司主线呼叫的总机接线员。一旦电话号码和设备安装成功且接线员到达时，服务就可以 开始了。
这个过程与网络世界一样，一旦一个通信端点已经建立，监听服务器就可以进入无限循 环中，等待客户端的连接并响应它们的请求。当然，为了使公司电话接待员一直处于忙碌状 态，我们绝不能忘记将电话号码放在公司信笺、广告或一些新闻稿上；否则，将没有人会打 电话过来! 相似地，必须让潜在的客户知道存在这样的服务器来处理他们的需求；否则，服务器将 永远不会得到任何请求。想象着创建一个全新的网站，这可能是最了不起的、劲爆的、令人 惊异的、有用的并且最酷的网站，但如果该网站的 Web 地址或 URL 从来没有以任何方式广 播或进行广告宣传，那么永远也不会有人知道它，并且也将永远不会看到任何访问者。 现在你已经非常了解了服务器是如何工作的，这就已经解决了较困难的部分。客户端比 服务器端更简单，客户端所需要做的只是创建它的单一通信端点，然后建立一个到服务器的 连接。然后，客户端就可以发出请求，该请求包括任何必要的数据交换。一旦请求被服务器 处理，且客户端收到结果或某种确认信息，此次通信就会被终止。
套接字
套接字是计算机网络数据结构，它体现了上节中所描述的“通信端点”的概念。在任何 类型的通信开始之前，网络应用程序必须创建套接字。可以将它们比作电话插孔，没有它将 无法进行通信。 套接字的起源可以追溯到 20 世纪 70 年代，它是加利福尼亚大学的伯克利版本 UNIX（称 为 BSD UNIX）的一部分。因此，有时你可能会听过将套接字称为伯克利套接字或 BSD 套接 字。套接字最初是为同一主机上的应用程序所创建，使得主机上运行的一个程序（又名一个 进程）与另一个运行的程序进行通信。这就是所谓的进程间通信（Inter Process Communication， IPC）。有两种类型的套接字：基于文件的和面向网络的。 UNIX 套接字是我们所讲的套接字的第一个家族，并且拥有一个“家族名字”AF_UNIX （又名 AF_LOCAL，在 POSIX1.g 标准中指定），它代表地址家族（address family）： UNIX。 包括 Python 在内的大多数受欢迎的平台都使用术语地址家族及其缩写 AF；其他比较旧的系 统可能会将地址家族表示成域（domain）或协议家族（protocol family），并使用其缩写 PF而 非 AF。类似地，AF_LOCAL（在 2000～2001 年标准化）将代替 AF_UNIX。然而，考虑到 后向兼容性，很多系统都同时使用二者，只是对同一个常数使用不同的别名。Python 本身仍 然在使用 AF_UNIX。
因为两个进程运行在同一台计算机上，所以这些套接字都是基于文件的，这意味着文件 系统支持它们的底层基础结构。这是能够说得通的，因为文件系统是一个运行在同一主机上 的多个进程之间的共享常量。 第二种类型的套接字是基于网络的，它也有自己的家族名字 AF_INET，或者地址家族： 因特网。另一个地址家族 AF_INET6 用于第 6 版因特网协议（IPv6）寻址。此外，还有其他 的地址家族，这些要么是专业的、过时的、很少使用的，要么是仍未实现的。在所有的地址 家族之中，目前 AF_INET 是使用得最广泛的。 Python 2.5 中引入了对特殊类型的 Linux 套接字的支持。套接字的 AF_NETLINK家族（无 连接[见2.3.3节]）允许使用标准的BSD套接字接口进行用户级别和内核级别代码之间的IPC。 之前那种解决方案比较麻烦，而这个解决方案可以看作一种比前一种更加优雅且风险更低的 解决方案，例如，添加新系统调用、/proc 支持，或者对一个操作系统的“IOCTL”。 针对 Linux 的另一种特性（Python 2.6 中新增）就是支持透明的进程间通信（TIPC）协 议。TIPC 允许计算机集群之中的机器相互通信，而无须使用基于 IP 的寻址方式。Python 对 TIPC 的支持以 AF_TIPC 家族的方式呈现。 总的来说，Python 只支持 AF_UNIX、AF_NETLINK、AF_TIPC 和 AF_INET 家族。因为 本章重点讨论网络编程，所以在本章剩余的大部分内容中，我们将使用 AF_INET。
套接字地址：主机-端口对
如果一个套接字像一个电话插孔——允许通信的一些基础设施，那么主机名和端口号就 像区号和电话号码的组合。然而，拥有硬件和通信的能力本身并没有任何好处，除非你知道 电话打给谁以及如何拨打电话。一个网络地址由主机名和端口号对组成，而这是网络通信所 需要的。此外，并未事先说明必须有其他人在另一端接听；否则，你将听到这个熟悉的声音 “对不起，您所拨打的电话是空号，请核对后再拨”。你可能已经在浏览网页的过程中见过一 个网络类比，例如“无法连接服务器，服务器没有响应或者服务器不可达。” 有效的端口号范围为 0～65535（尽管小于 1024 的端口号预留给了系统）。如果你正在使 用 POSIX 兼容系统（如 Linux、Mac OS X 等），那么可以在/etc/services 文件中找到预留端口 号的列表（以及服务器／协议和套接字类型）。
面向连接的套接字与无连接的套接字
1．面向连接的套接字
不管你采用的是哪种地址家族，都有两种不同风格的套接字连接。第一种是面向连接的， 这意味着在进行通信之前必须先建立一个连接，例如，使用电话系统给一个朋友打电话。这 种类型的通信也称为虚拟电路或流套接字。
面向连接的通信提供序列化的、可靠的和不重复的数据交付，而没有记录边界。这基本 上意味着每条消息可以拆分成多个片段，并且每一条消息片段都确保能够到达目的地，然后 将它们按顺序组合在一起，最后将完整消息传递给正在等待的应用程序。 实现这种连接类型的主要协议是传输控制协议（更为人熟知的是它的缩写 TCP）。为 了 创建 TCP 套接字，必须使用 SOCK_STREAM 作为套接字类型。TCP 套接字的名字 SOCK_STREAM 基于流套接字的其中一种表示。因为这些套接字（AF_INET）的网络版本 使用因特网协议（IP）来搜寻网络中的主机，所以整个系统通常结合这两种协议（TCP 和 IP） 来进行（当然，也可以使用 TCP 和本地[非网络的 AF_LOCAL/AF_UNIX]套接字，但是很明 显此时并没有使用 IP）。
2．无连接的套接字
与虚拟电路形成鲜明对比的是数据报类型的套接字，它是一种无连接的套接字。这意味 着，在通信开始之前并不需要建立连接。此时，在数据传输过程中并无法保证它的顺序性、 可靠性或重复性。然而，数据报确实保存了记录边界，这就意味着消息是以整体发送的，而 并非首先分成多个片段，例如，使用面向连接的协议。 使用数据报的消息传输可以比作邮政服务。信件和包裹或许并不能以发送顺序到达。 事实上，它们可能不会到达。为了将其添加到并发通信中，在网络中甚至有可能存在重复 的消息。 既然有这么多副作用，为什么还使用数据报呢（使用流套接字肯定有一些优势）？由于面 向连接的套接字所提供的保证，因此它们的设置以及对虚拟电路连接的维护需要大量的开销。 然而，数据报不需要这些开销，即它的成本更加“低廉”。因此，它们通常能提供更好的性能， 并且可能适合一些类型的应用程序。 实现这种连接类型的主要协议是用户数据报协议（更为人熟知的是其缩写 UDP）。为 了 创建 UDP 套接字，必须使用 SOCK_DGRAM 作为套接字类型。你可能知道，UDP 套接字的 SOCK_DGRAM 名字来自于单词“datagram”（数据报）。因为这些套接字也使用因特网协议 来寻找网络中的主机，所以这个系统也有一个更加普通的名字，即这两种协议（UDP 和 IP） 的组合名字，或 UDP/IP。
相关模块
当开发低级套接字 程序时，经常配合使用 select 模块和 socket 模块。select 模块提供了 select()函数，该函数 管理套接字对象集合。它所做的最有用的一个事情就是接收一套套接字，并监听它们活动 的连接。select()函数将会阻塞，直到至少有一个套接字已经为通信做好准备，而当其发生时，它将提供一组准备好读信息的集合（它还可以确定哪些套接字准备好写入，虽然它不像前一 种操作那么常见）。
在创建服务器方面，async*和 SocketServer 模块都提供更高级的功能。它们以 socket 和/ 或 select 模块为基础编写，能够使客户端/服务器系统开发更加迅速，因为它们已经自动处理 了所有的底层代码。你需要做的所有工作就是以自己的方式创建或继承适当的基类。正如前 面所提到的，SocketServer 甚至提供了将线程或新进程集成到服务器的功能，它提供了一个 更像并行处理的客户端请求的流程。 虽然在标准库中 async*提供了唯一的异步开发支持，但是在前一节中，我们引入了一个 比旧版本更加强大的第三方包 Twisted。虽然本章中我们已经看到的示例代码稍长于粗糙的脚 本，但是 Twisted 提供了一个更加强大
全文共6128字，剩余内容已隐藏，支付完成后下载完整资料
资料编号：[12066]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
