其中有些限制比现实更常出现. 数据报模型非常适合这样的应用程序 : (a) 请求 - 回复的交易 (FIXME:Transactions are request-reply). (b) 负载比较小. (c) 服务器是无连接的. (d) 事务是幂等的 (FIXME:Transactions are i

Size: px

Start display at page:

Download "其中有些限制比现实更常出现. 数据报模型非常适合这样的应用程序 : (a) 请求 - 回复的交易 (FIXME:Transactions are request-reply). (b) 负载比较小. (c) 服务器是无连接的. (d) 事务是幂等的 (FIXME:Transactions are i"

鸿郭
7 years ago
Views:

1 这章介绍 UDP, 用户数据报协议, 和它在 Java 中的实现 DatagramSocket 和 DatagramPacket. 在这章我们只关注阻塞模式的点对点或者 " 单播 "UDP.UDP 通道 I/O 和非阻塞模式在第 10 章组播 (MulticaseSocket) 中讨论, 广播在第 11 章讨论. 9.1 概览在这节我们简要浏览基本的单播 UDP 和如何在 Java 中编程. UDP 是指定在 RFC 768 中修订的 UDP 中的套接字如我们在节看到的, 一个套接字是一个通信端点的抽象表示, 与本机的一个 IP 地址和端口关联. 在 UDP 套接字和 TCP 套接字之间有重大 (significant) 的区别 : (a) UDP 套接字没有实现可靠的数据流. 它们实现了不可靠的数据报, 如在节讨论的. (b) UDP 只有 " 主动的 " 套接字, 与 TCP 对比,TCP 有 " 主动的 " 和 " 被动的 " 套接字. (c) UDP 没有如 TCP 中的明确的 "accept" 阶段 (*). (d) UDP 套接字没有明确的通过网络操作同时连接或者断开 (FIXME:UDP sockets are not explicitly connected together or disconnected by network operations-together 出现在这里有点让人不太明白 ). (e) UDP 套接字在 Java 中由 DatagramSocket 类型的对象表示. UDP 套接字和 TCP 套接字占据不同的 " 名称空间 ": 一个 TCP 套接字和一个 UDP 套接字总是有区别的, 即使他们有相同的地址和端口.UDP 套接字和 TCP 套接字不能交互连接. * 如节中讨论的, 为了避免某些 Java 和内核的开销. 一个发送者在做大量的发送之前可能会 ' 连接 ' 到远程地址和端口. 这是一个本地操作, 不是网络操作 : 远程端不知道这个操作和任何的通信断开连接操作数据报 ' 数据报 ' 是一个单一的传输, 可能传递 0 次或多次. 在同样的两个端点之间相对于 (with respect to) 其它的数据报它的顺序是不能保证的.(FIXME:Its sequencing with respect to other datagrams between the same two endpoints is not guaranteed) 换句话说, 它可能是无序传递的, 或根本没有, 或多次. 数据报在一个单一的 IP 数据包中发送. 不像 TCP 流, 数据报受限于 (subject to) 于大小的约束. (a) IPv4 协议限制它们为字节, 大部分实现限制它们为 8KB, 尽管在一些实现中可以通过增加套接字的发送和接收缓冲区大小增加提高这个, 如 9.11 节描述的. (b) IPv4 路由器有权 (entitle) 去分段任何的 IP 数据包, 包括 TCP 分段和 UDP 数据报. 不像 TCP 分段, 然而,UDP 数据报一旦被分段永远不会重新组装 (reassemble), 所以实际上被废弃了.IPv4 UDP 的实际开发通常限制消息为 521 字节 - 单个 IP 数据包 - 为了避免分段问题 (*). (c) IPv6 在 IP 层级上有 "jumbograms"(fixme:jumbograms 查不出来是啥意思 ); 这个允许 UDP 数据报达到 2-1 字节 ; 见 RFC 然而,RFC 接着说到 (FIXME:Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs. In other words, jumbograms can only be expected to be communicable among hosts which are all connected to such links.) 如果一个数据报完全传递, 它完整的达到, 也就是说, 没有传输错误, 丢弃和在字节中没有内部的顺序错误. 然而, 如果接收到的数据报大于可用空间, 超过的数据安静的被忽略. * UDP 的好处 (a) 由于协议是无连接的, 连接或断开连接不需要网络开销 (overhead). 作为对比, 我们已经在节看到 TCP 需要三方数据包交换去建立连接, 断开它需要四方数据包交换. (b) UDP 服务器的架构比 TCP 服务器的架构更加简单, 没有连接的套接字去接收和关闭. (c) 类似的,UDP 客户端的架构也比 TCP 客户端简单, 无需连接去创建或终止 UDP 的限制 (a) 不支持重新组装分段的数据报. (b) 在实践中负载是非常有限的. 数据报负载超过 512 字节会被路由器恰当的 (apt) 的分段, 因此实际上会丢失 (FIXME:therefore effectively lost). (c) 不支持根据一般的网络条件 (FIXME: pacing transmissions) (d) 不支持数据包排序. (e) 不探测数据包丢失和重新传输.

2 其中有些限制比现实更常出现. 数据报模型非常适合这样的应用程序 : (a) 请求 - 回复的交易 (FIXME:Transactions are request-reply). (b) 负载比较小. (c) 服务器是无连接的. (d) 事务是幂等的 (FIXME:Transactions are idempotent). 也就是说, 可以重复而不会影响全部 (overall) 的计算结果 (*). 数据报模型比 TCP 的流模型更加接近于实际的底层网络 : 包被交换, 重新排序和丢失. 数据报模型也比 TCP 流模型更加接近于许多应用程序的上层实现 (overlying realities). 本质上, 数据报自然地提供了在 " 最后一个 0" 的传递保证. 这个使得客户端看到发送的请求相当简单 : 可以是传输已经接收到和确认, 或者它被重新传输. xxxxxxx 总结,UDP 支持不可靠, 无连接, 大小限制的数据报通信在点对点架构中. 每个端点创建一个数据报套接字. 为了接收数据,UDP 套接字必须绑定到一个端口. 为了发送数据, 一个数据报的数据包形成, 通过一个数据报套接字发送到一个远程的 IP 地址和端口. 尽管 UDP 是一个点对点的协议, 在许多实际的应用程序中, 我们可以仍然区分作为客户端的发送请求的请求端点和等待回复, 和作为服务器等待一个请求的响应端点和发送一个回复. * 导入语句下面的 Java 导入语句假设在这章的示例中至始至终存在. import java.io.*; import java.net.*; import java.util.*; 9.2 简单的 UDP 服务器和客户端在 Java 中, 一个 UDP 套接字由 java.net.datagramsocket 类型的对象表示 ; 一个 UDP 数据包由 java.net.datagrampacket 类型的对象表示简单的简单的 UDP 服务器最简单的可行的 UDP 服务器在 Example 9.1 中展示. public class UDPServer implements Runnable { DatagramSocket socket; public UDPServer(int port) throws IOException { this.socket = new public void run() { for (;;) { try { byte[] buffer = new byte[8192]; DatagramPacket packet= new DatagramPacket(buffer, buffer.length); socket.receive(packet); new ConnectionHandler(socket, packet).run(); // 这里只是普通的方法调用, 并没有启动线程. catch (IOException e) { // // for (;;) // run() // class Example 9.1 Simple UDP server 这个的连接处理类和随后的服务在 Example 9.2 中展示. class ConnectionHandler implements Runnable { DatagramSocket socket; DatagramPacket packet; ConnectionHandler(DatagramSocket socket, DatagramPacket packet) { this.socket = socket;

3 this.packet = public void run() { handlepacket(socket, packet); public void handlepacket(datagramsocket socket, DatagramPacket packet) { try { byte[] buffer = packet.getdata(); int offset = packet.getoffset(); int length = packet.getlength(); // conversation not shown // sets reply into buffer/offset/length packet.setdata(buffer, offset, length); // write reply to the output socket.send(packet); catch (IOException e) { /*... */ // handlepacket() // class Example 9.2 UDP server connection handler Example 9.1 是单线程设计的通常不怎么适用, 由于它是顺序的处理客户端, 不是并发的 - 一个新的客户端阻塞当之前的客户端在服务中. 为了处理客户端并发, 服务器必须使用为接收的连接使用一个不同的线程. 这样的 UDP 服务器的最简单的的形式, 使用了相同的连接处理类, 在 Example 9.3 中描述. public class ConcurrentUDPServer extends UDPServer { public ConcurrentUDPServer(int port) throws IOException { public void run() { for (;;) { try { byte[] buffer= new byte[8192]; DatagramPacket packet = new DatagramPacket(buffer, buffer.length); socket.receive(packet); new Thread(new ConnectionHandler(socket, packet)).start(); // 启动一个新的线程 catch (IOException e) { // // for (;;) // run() // class Example 9.3 Simple UDP server multithreaded 连接处理类简化了回复它的输入到它的输出 - 对于测试非常有用 - 在示例 9.4 展示. class EchoConnectionHandler implements Runnable { DatagramSocket socket; DatagramPacket packet; ConnectionHandler(DatagramSocket socket, DatagramPacket packet) { this.socket = socket; this.packet = public void run() { handlepacket(socket, packet); public void handlepacket(datagramsocket socket, DatagramPacket packet) { try { byte[] buffer = packet.getdata(); int offset = packet.getoffset(); int length = packet.getlength(); // The reply is the same as the request, // which is already in buffer/offset/length packet.setdata(buffer, offset, length); // write reply to the output -- 写入回复到输出中 socket.send(packet); catch (IOException e) {

4 // // handlepacket() // class Example 9.4 UDP server connection handler echo service 简单的 UDP 客户端客户端的 DatagramSocket 通常绑定到系统选择的端口. 一个为之前的 UDP 服务器的简单的 UDP 客户端在 Example 9.5 展示. public class UDPClient implements Runnable { DatagramSocket socket; // socket for communications InetAddress address; // remote host int port; // remote port public UDPClient(InetAddress address, int port) throws IOException { this.socket = new DatagramSocket();// ephemeral port - 临时端口 this.address = address; this.port = port; /** * Send the data in {buffer, offset, length * and overwrite it with the reply. the actual reply length. IOException on any error */ public int sendreceive(byte[] buffer, int offset, int length) throws IOException { try { // Create packet DatagramPacket packet = new DatagramPacket (buffer, offset, length, address, port); socket.send(packet); socket.receive(packet); return packet.getlength(); catch (IOException e) { // // sendreceive() // class Example 9.5 Simple UDP client DatagramPacket 类如我们在节所看到的, 一个 UDP 数据报是一个单独的传输单元, 在 Java 中它很方便的作为一个单独的对象表示. 这个对象是 DatagramPacket.UDP 不是流协议, 所以 TCP 的基于流的编程技术用在 UDP 中不适用. 不像 TCP 套接字, 支持所熟悉的 InputStream 和 OutputStream,UDP 套接字在 Java 中通过发送和接收全部的 DatagramPacket 的方法支持输入和输出 DatagramPacket 构造函数一个 DatagramSocket 通过下面的方法中的一个构造 : class DatagramPacket { DatagramPacket(byte[] data, int length); DatagramPacket(byte[] data, int length, InetAddress address, int port); DatagramPacket(byte[] data, int offset, int length); DatagramPacket(byte[] data, int offset, int length, InetAddress address, int port); DatagramPacket(byte[] data, int length, SocketAddress socketaddress); DatagramPacket(byte[] data, int offset, int length, SocketAddress socketaddress); length 和 offset 是非负数, 下面的等式是适用的 (*): 0 length + offset data.length (EQ 9-1) 注意, 不像 TCP 协议, 在 UDP 中可能发送和接收都是 0 长度的数据报. 这在一个应用程序协议中可能是有用的, 比如,'I'm alive' 消息或者 pings. data,offset,length,address 和端口属性都可以单独设置在构造之后通过相应的 set 方法, 它们也都可以使用相应的 get 方法获取. 这些属性在下面将单独描述. * 这个等式在 Java 中总是适用的当处理字节数组的时候,offset 和 length, 通过任意的构造函数或者方法

5 执行的时候都会执行. 如果违背这个等式将抛出 IllegalArgumentException DatagramPacket data data 在一个 DatagramPacket 被指定为一个字节数组,offset 和 length. 这些可以在构造中一起设置, 也可以随后通过下面的方法设置和获取. class DatagramPacket { byte[] getdata(); void setdata(byte[] data); void setdata(byte[] data, int length); void setdata(byte[] data, int offset, int length); int getlength(); void setlength(int length); int getoffset(); void setoffset(int offset); data,offset 和 length 的默认值分别为 null,0 和 0. 当设置任意的这些属性的时候. 等式 9.1 将强制执行. 当发送一个数据报, 由应用程序决定格式化数据为字节数组. 这样做的一种方式就是 DataOutputStream, 或者 ObjectOutputStream, 结合到 ByteArrayOutputStream. DatagramPacket packet = new DatagramPacket(); ByteArrayOutputStream baos = new ByteArrayOutputStream(); DataOutputStream dos = new DataOutputStream(baos); dos.writeint( ); // or as per application protocol dos.flush(); packet.setdata(baos.tobytearray(), baos.size()); 当接收一个数据报,Java 将接收到数据放置到 DatagramPacket 的字节数组中从当前的 offset 属性值开始, 到 DatagramPacket 的当前的 length 属性的前一个结束. 应用程序必须预分配字节数组, 保证它能对于预期的数据是充分的. 同时设置适当的 offset 和 length: 字节数字,offset, 和长度必须满足等式 9.1. 通常应用程序将设置 offset 为 0,length 为字节数组的长度在接收到一个 DatagramPacket 之前. Java 调整 DatagramPacket 的 length 属性为接收到的数据的长度如果它小于原始的长度 ; 然而, 如我们在节所看到的, 超过的数据将被安静的截断, 长度不会受到干扰 : 换句换说, 没有迹象表明 ( 如过度长度 ) 接收数据被截断. 这意味着一个 datagram 的 length 属性在多次接收操作中重用, 但必须在第二次和随后的接收之前重置 ; 否则, 它不断的 (continually) 缩减 (shrinks) 到目前为止最小的 datagram 的大小. 它也意味着, 应用程序不能区分一个数据报的精确的最大长度和数据报太大被截断了. 通常处理这个问题的技术就是分配最大的预期的数据报加 1 个字节的空间. 如果一个数据报的额外的长度接收到了, 这是出乎意料的, 也就是说, 至少一个字节太长 (FIXME:It also means that the application can t distinguish between a datagram which was exactly the maximum length and a datagram which was too big and got truncated. The usual technique for handling this problem is to allocate space for the largest expected datagram plus one byte. If a datagram of this extra length is received, it was unexpectedly large, i.e. at least one byte too long). 由应用程序决定格式化数据为字节数组. 这样做的一种方式就是 DataInputStream, 或者 ObjectInputStream, 结合到 ByteArrayInputStream. DatagramPacket packet; // initialization & receive not shown ByteArrayInputStream bais = new ByteArrayInputStream(packet.getData(), packet.getoffset(), packet.getlength()); DataInputStream dis = new DataInputStream(bais); int i = dis.readint();// or as per application protocol 应该要清楚这个技术是这节之前给出的 ByteArrayOutputputStream 技术的倒转 DatagramPacket 地址和端口一个 DatagramPacket 关联一个 IP 地址和端口 : 这些代表了来自于哪里的一个绑定的 datagram 的远程的 UDP 套接字. 或者一个未绑定的 datagram 正在被发送. 它们可以通过构造函数或下面的方法设置 : class DatagramPacket { SocketAddress getsocketaddress(); void setsocketaddress(socketaddress address); InetAddress getaddress(); void setaddress(inetaddress address); int getport(); void setport(int port);

6 要记住 JDK 1.4 SocketAddress 代表了一个 {InetAddress, port 对. 当一个数据报被接收,Java 设置它的 {addressm port 到它的数据报的远程源 (FIXME:remote source), 这样你可以知道它从哪里来. 当发送一个数据报, 它的 {address, port 必须已经设置到了数据报将要被发送的目标. 如果数据报启动会话 (initiates the conversation), 应用程序必须设置自身的 {address, port. 然而, 回复一个刚接收到的数据报, 它只是简单的重用接收到的数据报 : 使用 DatagramPacket.setData 方法将回复的数据放到数据报中, 保持 {address, port 原样, 而不是构造一个新的 DatagramPacket 和设置它的 {address, port. 这种技术可以节省创建对象, 在请求和回复之间避免易于出错的拷贝 {address, port. 9.3 数据报套接字初始化构造 DatagramSocket 使用下面的构造函数之一创建. DatagramSocket() throws IOException; DatagramSocket(int port) throws IOException; DatagramSocket(int port, InetAddress localaddress) throws IOException; DatagramSocket(SocketAddress localsocketaddress) throws IOException; 在大多数这样的情况下, 套接字构造已经 ' 绑定 ', 意味着它已经关联了一个本地的 IP 地址和端口. 一个绑定的套接字可以立即被使用, 用来发送和接收. 然而, 如果构造函数使用一个 null 的 SocketAddress, 套接字是 ' 未绑定 ' 构造的, 也就是说, 还没有关联一个本地的 IP 地址或者端口. 一个未绑定的套接字可以立即用来发送, 但是接收之前它必须首先使用 DatagramSocket.bind 来 ' 绑定 ', 在节描述. 首先我们看下构造绑定的套接字的构造的函数 ; 然后我们看下未绑定套接字的方法端口 UDP 接收端通常指定它们要接收的本地端口, 通过提供一个非 0 的端口到构造函数中或者 bind 方法. 如果端口省略或者为 0, 一个临时 - 系统分配 - 端口将被使用. 可以通过调用下面的方法获得 : int getlocalport(); 临时端口通常被 UDP 客户端使用, 除非他们需要去指定一个特殊的端口去满足本地的网络约束, 比如防火墙策略. 临时端口通常不会被 UDP 服务器使用, 由于一些外部因素通信需要实际的端口到客户端 (FIXME:as otherwise some external means is required of communicating the actual port number to clients); 否则我们不知道如何发送到接收器 : 通常这个功能假设通过命名服务比如一个 LDAP 目录服务. 在 Sun RPC, 假设通过 RPC 端口映射服务本地地址一个数据报套接字的本地地址是它接收的 IP 地址. 默认情况下,UDP 套接字在所有的本地 IP 地址上接收. 它们可以用来在一个单独的本地 IP 地址上接收, 通过提供一个非 null 的 InetAddress 或者带有非 null 的 InetAddress 的 InetSocketAddress, 到一个 DatagramSocket 的构造函数上. 如果 InetAddress 省略或为 null(' 通配符 ' 地址 ), 套接字绑定到所有的本地地址, 意味着它从任意的地址接收. 指定一个本地的 IP 地址只是更有意义, 如果本地主机是多地址的. 也就是说, 有多个 IP 地址, 通常因为它有多于 1 个的物理网络接口. 在这种的情况下, 一个 UDP 接收器可能只想去通过这些 IP 地址中的 1 个使得自身可用而不是它们中的所有. 查看在 9.12 节的多地址讨论获得更多细节. 一个数据报套接字绑定的 UP 地址通过以下地方方法返回 : InetAddress getinetaddress(); SocketAddress getlocalsocketaddress(); 这些方法返回 null, 如果套接字还没有绑定重用本地地址如早节所描述的在绑定数据报套接字之前, 你可能希望去设置 ' 重用本地地址 ' 选项. 这个实际上意味着重用本地端口. 重用 - 地址方法在 JDK 1.4 中加入 : void setreuseaddress(boolean reuse) throws SocketException; boolean getreuseaddress() throws SocketException;

7 你必须使用这个设置如果你想在相同的端口在多 IP 地址上接收通过绑定多个 DatagramSocket 到相同端口和不同的本地 IP 地址, 要么在相同的 JVM 中或者在相同主机的多个 JVM 中. 在一个数据报套接字绑定, 或者构造除了使用一个 null SocketAddress 后改变这个设置, 不会有效果. 注意这个方法设置和获取一个 boolean 状态, 而不是一些某种形式的地址如它们的名称可能建议的 (FIXME:not some sort of address as their names may suggest.) Bind 操作一个 DatagramSocket 构造使用一个 null SocketAddress 在构造函数中在 JDK 1.4 中引入必须在数据报可以接受之前绑定 ( 尽管它不需要为数据报被发送而绑定 ). 数据报的绑定由 JDK 1.4 的方法支持. void bind(socketaddress localsocketaddress) throws IOException; boolean isbound(); localsocketaddress 通常是一个使用一个端口的 InetSocketAddress, 如节所描述的.InetAddress 如节描述. 套接字要么绑定到一个临时端口, 要么绑定到一个指定的本地端口, 在一个指定的本地 IP 地址或者它们中的所有, 根据 localsocketaddress 参数的值, 如表格 9.1 所示. 表格 9.1 UDP bind 参数 SocketAdddress InetAddres port Bound To null - - 临时端口, 所有的本地 IP 地址 InetSocketAddress null zero 临时端口, 所有的本地 IP 地址 InetSocketAddress null non-zero 指定端口, 所有的本地 IP 地址 InetSocketAddress non-null zero 临时端口, 指定的本地 IP 地址 InetSocketAddress non-null non-zero 指定的端口和本地 IP 地址如在节所讨论的, 一个服务器通常应该指定一个特殊的端口 : 客户端可以这样也可以不这样, 主要依赖于它是否需要因为防火墙 - 穿透 (firewall-traversal) 目的使用一个固定的端口.bind 方法必须在执行通道数据报输入之前被调用, 将在 10.2 节讨论. 多地址的主机在 9.12 节讨论. 一个 DatagramSocket 不能被重新绑定.isBound 方法返回 true 如果套接字已经绑定设置缓冲区大小在使用一个数据报套接字之前, 它的发送和接收缓冲区大小应该被调整, 如 9.11 节描述的 Connect 操作一个 DatagramSocket 可以连接到一个远程的 UDP 套接字. 不像 TCP 的连接操作, 一个 UDP ' 连接 ' 只是一个本地的操作 : 它不影响网络, 因此它不会影响远程端 ; 它仅仅 (conditions) 作为本地端的条件, 这样数据可以接收或者发送到指定的地址. 如果一个传入的 DatagramPacket 的 {address,port 属性与设置指定到 connect 方法中的不一致, 数据报将被安静地废弃 ; 如果一个输出的 DatagramPakcet 的这些与指定到 connect 方法中的设置不一致,DatagramSocket.send 将抛出 IllegalArgumentException. 数据报套接字的连接通过下面的方法支持 : void connect(inetaddress address, int port); void connect(socketaddress socketaddress) throws SocketException; boolean isconnected(); (a) address 和 port 指定了一个远程 UDP 套接字的 {address, port, 如在节描述的, 或者 (b) sokcetaddress 通常是一个 InetSocketAddress 使用一个远程 UDP 套接字 {address, port 构造, 如节所描述的. 由于没有涉及网络协议, 不能保证远程 UDP 端口存在, 即使 connect 方法可能已经成功完成. 因此随后的在一个连接的 DatagramSocket 上的发送或者接收操作可能抛出 PortUnreachableException. 更坏的是, 发送和接收可能简单的安静失败而不会抛出异常. 实际的行为的发生依赖于平台和 JDK 版本. 连接一个数据报套接字节省 Java 开销 : 它允许连接允许到目标上只在连接的时候被检查, 而不是在每次传输或者从目标接收. 如果请求的 'connct' 行为的 SocketPermission 没有授予 (granted), 将抛出 SecurityException: 这是一个运行时错误, 编译的时候不会被检查. 在 Berkeley 套接字 API 中, 连接一个数据报套接字也减少了某些内核的开销. 在 JDK 1.4 之前,Java 不是调用底层的 connect()api, 它只是在 Java 层面模仿它的行为, 这样内核开销不会减少,PortUnreachableException 不是由在一个连接的 DatagramSocket 上的 I/O 操作抛出.

8 isconnect 方法判断本地套接字是否已经连接 : 它不会告诉你关于另一个端点的信息, 包含它是否存在. 一个 DatagramSocket 不能被关闭然后连接或者重新连接, 但是它可以被断开连接如 9.5 节描述, 然后重新连接. 如果你没有 JDK 1.4, 和它的 DatagramSocket.isConnect 方法, 你可以使用下面的方法 : InetAddress getinetaddress(); int getport(); 为了相同的目的. 这些方法返回连接的套接字的远程地址或断开, 或者 null 或者 -1( 视情况而定 ), 如果套接字当前没有连接. 9.4 数据报 I/O 数据报 I/O 通过下面的方法执行 : void send(datagrampacket packet) throws IOException: void receive(datagrampacket packet) throws IOException: 数据报输出一旦你已经格式化输出数据到一个字节数组中, 然后使用一个来自它的 DatagramPacket 构造, 如节所示, 在数据报中设置地址, 如节所示, 发送谁到目的地只是简单的调用 DatagramSocket.send 方法, 如下面所示 : // initializations not shown InetAddress address; DatagramPacket packet; int port; byte[] buffer;// see section DatagramSocket socket = new DatagramSocket(); packet.setdata(buffer, length); // pre-jdk 1.4 packet.setaddress(address); packet.setport(port); socket.send(packet); 从 JDK 1.4 开始,setAddress 和 setport 的调用可以单独调用 setsocketaddress 来替代 : // From JDK 1.4 packet.setsocketaddress(new InetSocketAddress(address, port)); DatagramSocket.send 方法不是同步的 : 这就是为什么在 Example 9.2.1( 书中写的是 9.3, 应该是错误的 ) 中所展示的并发的 UDP 服务器不需要第二个 DatagramSocket 去发送回复给传入的数据包. 任何内部的顺序需要由底层 UDP 实现处理.( 这段说的其实有点让人不是那么理解, 不过可以看下 send() 方法的源实现, 虽然此方法不是同步的, 但是此方法的内部, 其实是做了同步操作的 ) 数据报套接字的异常处理在 9.8 节讨论数据报输入接收数据报甚至比发送还简单, 如下面所示 : int port; // initialization not shown DatagramSocket socket = new DatagramSocket(port); // declare array at required length+1 byte[] buffer = new byte[8192+1]; DatagramPacket packet = new DatagramPacket(buffer, buffer.length); socket.receive(packet); 如果数据报在等待,receive 方法阻塞到一个数据报被接收到. 此时 packet.getdata 方法可以获得接收到的数据,packet.getOffset 为它的偏移位,packet.getLength 为它的总长度, 所以我们可以如下处理 : ByteArrayInputStream bais = new ByteArrayInputStream(packet.getData(), packet.getoffset(),packet.getlength()); // etc as in section 在这种情况下, 我们不用指定 offset 当创建 packet 的时候, 所有我们可以使用简单的形式 :

9 new ByteArrayInputStream(packet.getData(), packet.getlength()); // 尽管实际的编程中不应该像这样假设 offset 为 0. 如果我们想去回复这个数据报, 我们在看到过, 一个接受的数据报已经包含了发送者的地址和端口, 所以我们所要做的就是设置回复的数据然后调用如节描述的 DatagrmSocket.send. DatagramSocket.receive 方法不是同步的. 默认的数据报套接字实现类 ( 在 9.6 节讨论 ) 的 receive 方法是同步的. 从多线程中在同一个数据报套接字上并发接收是由 Java 进行顺序化的. 9.5 终止在 UDP 中没有明确的断开连接协议, 所以当一个会话由一个特定的端点结束, 不需要特别的动作. 连接的套接字数据报可以被断开, 如果需要的话可以在未连接或者连接的模式中重用 (FIXME:re-used in either unconnected or connected mode if required). 数据报套接字比粗在使用后关闭断开连接如果一个数据报套接字已经连接了, 它可以使用下面的方法断开 : void disconnect(); 这个方法什么都不做如果套接字没有连接. 如果一个数据报套接字用在了连接模式中, 它通常应该在一个会话的一开始就连接, 在会话结束的时候断开关闭当你用完了一个 DatagramSocket, 你必须关闭它 : void close() throws IOException; boolean isclosed(); isclosed 犯法判断本地套接字是否已经关闭. 它不会告诉你任何关于连接的信息,(FIXME: for the very good reason that in UDP there is no connection in the network sense). 在关闭后, 套接字不能再用来做任何事 (FIXME:the socket is no longer usable for any purpose). 9.6 套接字工厂如我们在节所看到的,java.net 套接字工厂由 Java 使用用来去提供它自身的套接字实现. java.net.datagramsocket 类实际上是表面的. 它定义了 Java 套接字 API, 但是代理了它 ( 做所有的实际的工作 ) 的所有的动作到套接字实现对象, 数据报套接字实现继承了抽象 java.net.datagramsocketimpl 类 : class DatagramSocketImpl { // 工厂提供了 DatagramSocketImpl 类型的对象, 实现了 java.net.datagramsocketimpfactory 接口 : interface DatagramSocketImplFactory { DatagramSocketImpl createdatagramsocketimpl(); 一个默认的套接字工厂总是被设置的, 产生包保护的 java.net.plaindatagramsocketimpl 类的对象. 这个类有本地的方法, 与本地的 C- 语言套接字 API 交互. 比如,Berkeley 套接字 API 或者 Win sock. 套接字工厂可以这样设置 : static void setdatagramsocketimplfactory(datagramsocketimplfactory factory);

setdatagramsocketimplfactory( 书中写的是 setsocketfactory, 是简写还是写错了?) 方法在 JVM 的生命周期中只能被调用一次. 它需要 RuntimePermission 'setfactory' 被授予, 否则将抛出 SecurityException. 应用程序很少或者无需使用这个工具. 9.

10 setdatagramsocketimplfactory( 书中写的是 setsocketfactory, 是简写还是写错了?) 方法在 JVM 的生命周期中只能被调用一次. 它需要 RuntimePermission 'setfactory' 被授予, 否则将抛出 SecurityException. 应用程序很少或者无需使用这个工具. 9.8 许可 (Permissions) 如果 Java2 安全管理被安装, 数据报套接字操作需要各种 java.net.socketpermissions. 这些在表 9.2 展示. 动作 accept 说明表 9.2 UDP 中的许可在 DatagramSocket 的 receive 和 connect 方法中需要. 目标主机和端口指定了远程 UDP 套接字. 在 connect DatagramSocket 的 send 和 connect 方法中需要, 当获取 InetAddress 对象的时候. 目标主机和端口指定了远程 UDP 套接字 ( 书中多了 and port 字样 ). 当构造 DatagramSocket 的时候需要, 和在它的 bind 方法中. 目标主机和端口指定了本地 listen UDP 套接字. 大多数指定为如 'localhost:1024'(fixme: Most loosely specified as "localhost:1024-"). 这个许可是 resolve 'connect' 操作必须 (imply) 的, 所以有必要明确地指定它. 目标主机和端口指定了远程 UDP 套接字. 9.8 异常有意义的的 Java 异常可能出现哎数据报套接字操作中在表 9.3 展示. 表 9.3 UDP 中的异常异常由.. 抛出含义 java.net.bindexception java.lang.illegalargumentexception DatagramSocket 构造函数和 bind 方法 DatagramSocket 的几个构造和方法 ;DatagramSocket 和 InetSocketAddress 的几个方法 java.nio.illegalblockingmodeexception DatagramSocket 的 send 和 receive 方法 DatagramSocket 的 java.io.interruptedioexception receive 方法 java.io.ioexception java.net.portunreachableexception java.lang.securityexception java.net.socketexception DatagramSocket 的 send 方法 DatagramSocket 的 send 和 receice 方法 DatagramSocket 的几个方法 DatagramSocket 的许多方法, 尤其是 receive DatagramSocket 的请求的本地地址或者端口不能被分配, 比如, 它已经在使用中, 并且 ' 重用地址 ' 选项没有设置违反了等式 9.1, 或者参数为 null 或者超出了范围. 这个一个 RuntimeException, 因此没有在方法的签名中出现, 或者被编译器检查. 套接字有一个管理的通道, 处于阻塞模式中. 从 JDK1.4 开始. 发生超时 ; 在 JDK 1.4 之前. 出现了一般的 I/O 错误. 从这个异常衍生出的异常包括 IllegalBlockingModeExcepion,InterruptedIOException, SocketException 和 UnkownHostException 套接字连接到一个当前不可达的目标. 从 JDK 1.4 开始. 需要的 SocketPermission 没有被授予, 如表格 9.2 所示. 这是一个 RuntimeExeption, 没有在方法签名中展示或者由编译器检查. 一个底层的 UDP 错误发生, 或者套接字被另一线程通过 DatagramChannel 的 close 方法关闭. 许多异常从这个异常衍生, 包括 BindException. 超时发生. 从 JDK 1.4 开始. 继承了 InterruptedIOException 为了

11 java.net.sockettimeoutexception java.net.unknownhostexception receive 方法了向后兼容 JDK1.4 之前的程序. InetAddress 的所有方法, 或者不明确使用这命名的 IP 地址主机不能决定 (FIXME:The IP address of the 些, 当使用 String 主机 named host cannot be determined). 名称的时候. 9.9 套接字选项有几个套接字选项可用, 控制 UDP 套接字的高级特性. 在 Java 中, 数据报套接字选项可用通过 java.net.datagramsocket 的方法设置和获取. 数据报套接字在下面展示, 按照它们相对重要的顺序. 在这章最后出现的一个选错, 是你最不需要关注的超时如我们已经在 3.12 节看到的 ( 将在和节再次看到 ), 不能假设一个应用程序可以永远等待一个远程的服务, 或者服务将永远以一种即时的方式回答 (rendered), 或者服务或者中间的 (intervening) 网络设置将以可探测的方式失败 (FIXME:the intervening network infrastructure will only fail in detectable ways). 任何读取无限超时的网络程序尽快或者随后将经历一个无限的延迟. 因为这些原因, 谨慎 (prudent) 的网络程序总是在客户端几乎使用一个有限的接收超时. 接收超时通过下面的方法设置和获取 : void setsotimeout(int timeout) throws SocketException; int getsotimeout() throws SocketException; timeout 用毫秒指定, 必须为一个正数, 表明一个有限的超时, 或者为 0, 表明一个无限的超时. 默认情况下, 读超时是无限的. 如果超时在套接字上一个阻塞的接收操作之前设置为一个有限的值, 接收将阻塞达到超时周期如果数据不可用, 然后将抛出 InterruptedIOException, 或者如表 9.3 所示,JDK 1.4 SocketTimeoutException 从它衍生而来. 如果超时是无限的, 接收将永远阻塞, 如果数据不可用并没有错误发生. 在 3.12 节关于 TCP 超时期间的特性同样适用于 UDP. UDP 服务器等待一个客户端请求不需要使用超时, 不像 TCP 服务器, 它们没有连接去终止. 一个 UDP 服务器超时在单个线程中可用来去轮询大量的 DatagramSocket, 尽管在节描述的 Selector 类提供了一种更好的方式去这么做缓冲区 UDP 为每个套接字分配发送缓冲区和接收缓冲区. 这些缓冲区存在于内核等待地址空间或者 UDP 协议栈 ( 如果不同的话 ), 而不是在 JVM 或者进程地址空间. 这些缓冲区的大小由底层平台的 UDP 实现决定, 而不是 Java. 在当前的 UDP 实现中, 发送和接收缓冲区大小至少为 8KB, 通常为 32KB, 或者更多, 可以设置如 256M 这么大或者在一些实现中更多. 在决定和如何去改变套接字缓冲区大小以前目标系统的特性必须被调查研究. 发送和接收缓冲区大小通过下面的方法设置和获取 : void setreceivebuffersize(int size) throws SocketException; int getreceivebuffersize() throws SocketException; int getsendbuffersize() throws SocketException; void setsendbuffersize(int size) throws SocketException; size 指定为字节, 提供给这些方法的值只是给底层平台一个示意, 在任何一个方向都可以被调整来适应合法的范围, 或者向上或者向下调整为适当的边界. 这些方法的返回值可能和你发送的值不匹配, 也可能与底层平台使用的实际值不匹配. 你可以在套接字关闭前的任意时刻执行这些操作一个数据报套接字的缓冲区应该多大?

interfaces which it implements): int read(bytebuffer) throws IOException; int read(bytebuffer[] buffers) throws IOException; int read(bytebuffer[] buf

interfaces which it implements): int read(bytebuffer) throws IOException; int read(bytebuffer[] buffers) throws IOException; int read(bytebuffer[] buf 这章讨论了 JDK 1.4 UDP 数据报可伸缩 I/O 的使用. 10.1 UDP 的通道在 UDP 之上的可伸缩 I/O 使用我们在之前 4.2.1 节所遇到的 DatagramChannel 类执行. 10.1.1 导入语句下面的 Java 导入语句假设在这章的示例中至始至终存在. import java.io.*; import java.net.*; import java.nio.*;