11.12 UDP服务器的设计
使用U D P的一些蕴含对于设计和实现服务器会产生影响。通常，客户端的设计和实现比
服务器端的要容易一些，这就是我们为什么要讨论服务器的设计，而不是讨论客户端的设计
的原因。典型的服务器与操作系统进行交互作用，而且大多数需要同时处理多个客户。
通常一个客户启动后直接与单个服务器通信，然后就结束了。而对于服务器来说，它启
动后处于休眠状态，等待客户请求的到来。对于 U D P来说，当客户数据报到达时，服务器苏
醒过来，数据报中可能包含来自客户的某种形式的请求消息。
在这里我们所感兴趣的并不是客户和服务器的编程方面（ [Stevens 1990]对这些方面的细
节进行了讨论），而是U D P那些影响使用该协议的服务器的设计和实现方面的协议特性（我们
在 1 8 . 11节中对T C P服务器的设计进行了描述）。尽管我们所描述的一些特性取决于所使用
U D P的实现，但对于大多数实现来说，这些特性是公共的。
11.12.1 客户IP地址及端口号
来自客户的是U D P数据报。 I P首部包含源端和目的端 I P地址，U D P首部包含了源端和目
的端的U D P端口号。当一个应用程序接收到 U D P数据报时，操作系统必须告诉它是谁发送了
这份消息，即源 I P地址和端口号。
这个特性允许一个交互 U D P服务器对多个客户进行处理。给每个发送请求的客户发回应
答。
11.12.2 目的IP地址
一些应用程序需要知道数据报是发送给谁的，即目的 I P地址。例如，Host Requirements
R F C规定，T F T P服务器必须忽略接收到的发往广播地址的数据报（我们分别在第 1 2章和第1 5
章对广播和T F T P进行描述）。
这要求操作系统从接收到的 U D P数据报中将目的 I P地址交给应用程序。不幸的是，并非
所有的实现都提供这个功能。
socket API以I P _ R E C V D S TADDR socket选项提供了这个功能。对于本文中使用的
系统，只有B S D / 3 8 6、4 . 4 B S D和AIX 3.2.2支持该选项。S V R 4、SunOS 4.x和Solaris 2.x
都不支持该选项。
11.12.3 UDP输入队列
我们在1 . 8节中说过，大多数U D P服务器是交互服务器。这意味着，单个服务器进程对单
个U D P端口上（服务器上的名知端口）的所有客户请求进行处理。
通常程序所使用的每个 U D P端口都与一个有限大小的输入队列相联系。这意味着，来自
不同客户的差不多同时到达的请求将由 U D P自动排队。接收到的 U D P数据报以其接收顺序交
给应用程序（在应用程序要求交送下一个数据报时）。
122使用TCP/IP详解，卷1：协议
下载
