当前位置:Linux教程 - Linux资讯 - Linux操作系统下广播程序制作介绍

Linux操作系统下广播程序制作介绍

TCP/IP网络的主要原理

在一个IP(Internet Protocol)网络中,每一台计算机都有一个32位的IP地址。每台计算机的IP地址都是唯一的。WWW是一个范围十分大,并且不断增长的IP网络,所以网络上的每台计算机都必须有一个唯一的IP地址。IP地址是用.分隔开的4个十进制数,例如16.42.0.9。实际上IP地址可以分为两部分:一部分是网络地址,另一部分是主机地址,例如,在16.42.0.9中,16.42是网络地址,0.9则为主机地址。而主机地址又可以分为子网地址和主机地址。计算机的IP地址很不容易记忆,如果使用一个名字就可以方便得多。如果使用名字,则必须有某一种机制将名字转化为IP地址。这些名字可以静态地保存在/etc/hosts文件中,或者Linux系统请求域名服务器(DNS服务器)来转换名字。如果使用DNS服务器的话,本地的主机则必须知道一个或者多个DNS服务器的IP地址,这些信息保存在/etc/resolv.conf文件中。

当你和其他计算机相连时,系统要使用IP地址和其他计算机交换数据。数据保存在IP数据包中。每一个IP数据包都有一个IP数据头,其中包括源地址和目的地址,一个数据校验和以及其他一些有关的信息。IP数据包的大小随传输介质的不同而不同,例如,以太网的数据包要大于PPP的数据包。目的地址的主机在接收数据包后,必须再将数据装配起来,然后传送给接收的应用程序。

连接在同一个IP子网上的主机之间可以直接传送IP数据包,而在不同子网之间的主机却要使用网关。网关用来在不同的子网之间传送数据包。

IP协议是一个传输层的协议,其他的协议可以利用IP协议来传输数据。TCP(Transmission Control Protocol)协议是一个可靠的点到点之间的协议,它使用IP协议来传送和接收自己的数据包。TCP协议是基于连接的协议。需要通信的两个应用程序之间将建立起一条虚拟的连接线路,即使其中要经过很多子网、网关和路由器。TCP协议保证在两个应用程序之间可靠地传送和接收数据,并且可以保证没有丢失的或者重复的数据包。当TCP协议使用IP协议传送它自己的数据包时,IP数据包中的数据就是TCP数据包本身。相互通信的主机中的IP协议层负责传送和接收IP数据包。每一个IP数据头中都包括一个字节的协议标识符。当TCP协议请求IP协议层传送一个IP数据包时,IP数据头中的协议标识符指明其中的数据包是一个TCP数据包。接收端的IP层则可以使用此协议标识符来决定将接收到的数据包传送到那一层,在这里是TCP协议层。

当应用程序使用TCP/IP通信时,它们不仅要指明目标计算机的IP地址,也要指明应用程序使用的端口地址。端口地址可以唯一地表示一个应用程序,标准的网络应用程序使用标准的端口地址,例如,web服务器使用端口80。你可以在/etc/services中查看已经登记的端口地址。

IP 协议层也可以使用不同的物理介质来传送IP数据包到其他的IP地址主机。这些介质可以自己添加协议头。例如以太网协议层、PPP协议层或者SLIP协议层。以太网可以同时连接很多个主机,每一个主机上都有一个以太网的地址。这个地址是唯一的,并且保存在以太网卡中。所以在以太网上传输IP数据包时,必须将IP数据包中的IP地址转换成主机的以太网卡中的物理地址。Linux系统使用地址解决协议( ARP)来把IP地址翻译成主机以太网卡中的物理地址。希望把IP地址翻译成硬件地址的主机使用广播地址向网络中的所有节点发送一个包括IP地址的ARP请求数据包。拥有此IP地址的目的计算机接收到请求以后,返回一个包括其物理地址的ARP应答。ARP协议不仅仅限于以太网,它还可以用于其他的物理介质,例如FDDI等。那些不能使用ARP的网络设备可以标记出来,这样Linux系统就不会试图使用ARP。系统中也有一个反向的翻译协议,叫做RARP,用来将主机的物理地址翻译成IP地址。网关可以使用此协议来代表远程网络中的IP地址回应ARP请求。

BSD 套接口

BSD 套接口是最早的网络通信的实现,它由一个只处理BSD 套接口的管理软件支持。其下面是INET套接口层,它管理TCP协议和UDP协议的通信末端。UDP(User Datagram Protocol)是无连接的协议,而TCP则是一个可靠的端到端协议。当网络中传送一个UDP数据包时,Linux系统不知道也不关心这些UDP数据包是否安全地到达目的节点。TCP数据包是编号的,同时TCP传输的两端都要确认数据包的正确性。IP协议层是用来实现网间协议的,其中的代码要为上一层数据准备IP数据头,并且要决定如何把接收到的IP数据包传送到TCP协议层或者UDP协议层。在IP协议层的下方是支持整个Linux 网络系统的网络设备,例如PPP和以太网。网络设备并不完全等同于物理设备,因为一些网络设备,例如回馈设备是完全由软件实现的。和其他那些使用mknod命令创建的Linux系统的标准设备不同,网络设备只有在软件检测到和初始化这些设备时才在系统中出现。当你构建系统内核时,即使系统中有相应的以太网设备驱动程序,你也只能看到/dev/eth0。ARP协议在IP协议层和支持ARP翻译地址的协议之间。

================================ 网络应用程序 用户层 -------------------------------- BSD 核心层 套接口层 LNET 套接口层 /   \ TCP UDP IP PPP SLIP Ethernet ---> ARP ================================

BSD是UNIX系统中通用的网络接口,它不仅支持各种不同的网络类型,而且也是一种内部进程之间的通信机制。两个通信进程都用一个套接口来描述通信链路的两端。套接口可以认为是一种特殊的管道,但和管道不同的是,套接口对于可以容纳的数据的大小没有限制。Linux支持多种类型的套接口,也叫做套接口寻址族,这是因为每种类型的套接口都有自己的寻址方法。

Linux的BSD 套接口支持下面的几种套接口类型:

1. 流式(stream)

这些套接口提供了可靠的双向顺序数据流连接。它们可以保证数据传输中的完整性、正确性和单一性。INET寻址族中的TCP协议支持这种类型的套接口。

数据流套接口是可靠的双向连接的通信数据流。如果你在套接口中以“ 1, 2”的顺序放入两个数据,它们在另一端也会以“1, 2”的顺序到达。它们也可以被认为是无错误的传输。

经常使用的telnet应用程序就是使用数据流套接口的一个例子。使用HTTP的WWW浏览器也使用数据流套接口来读取网页。事实上,如果你使用telnet 登录到一个WWW站点的8 0端口,然后键入“GET 网页名”,你将可以得到这个Html页。数据流套接口使用TCP得到这种高质量的数据传输。数据报套接口使用UDP,所以数据报的顺序是没有保障的。数据报是按一种应答的方式进行数据传输的。

2. 数据报(Datagram)

这种类型的套接口也可以像流式套接口一样提供双向的数据传输,但它们不能保证传输的数据一定能够到达目的节点。即使数据能够到达,也无法保证数据以正确的顺序到达以及数据的单一性、正确性。U D P协议支持这种类型的套接口。

3. 原始(Raw)

这种类型的套接口允许进程直接存取下层的协议。

4. 可靠递送消息(Reliable Delivered Messages)

这种套接口和数据报套接口一样,只能保证数据的到达。

5. 顺序数据包(Sequenced Packets)

这种套接口和流式套接口相同,除了数据包的大小是固定的。

6. 数据包(Packet)

这不是标准的BSD 套接口类型,而是Linux 中的一种扩展。它允许进程直接存取设备层的数据包。


[1] [2] [3] [4] [5] 下一页 

更多的请看:http://www.QQread.com/windows/2003/index.html

基本套接口选项

SO_KEEPALIVE

检测对方主机是否崩溃,避免(服务器)永远阻塞于TCP连接的输入。 设置该选项后,如果2小时内在此套接口的任一方向都没有数据交换,TCP就自动给对方 发一个保持存活探测分节(keepalive probe)。这是一个对方必须响应的TCP分节.它会导致以下三种情况:

对方接收一切正常:以期望的ACK响应。2小时后,TCP将发出另一个探测分节。

对方已崩溃且已重新启动:以RST响应。套接口的待处理错误被置为ECONNRESET,套接 口本身则被关闭。 对方无任何响应:源自berkeley的TCP发送另外8个探测分节,相隔75秒一个,试图得到 一个响应。在发出第一个探测分节11分钟15秒后若仍无响应就放弃。套接口的待处理错 误被置为ETIMEOUT,套接口本身则被关闭。如ICMP错误是“host unreachable(主机不 可达)”,说明对方主机并没有崩溃,但是不可达,这种情况下待处理错误被置为EHOSTUNREACH。

SO_RCVBUF和SO_SNDBUF 每个套接口都有一个发送缓冲区和一个接收缓冲区。 接收缓冲区被TCP和UDP用来将接收到的数据一直保存到由应用进程来读。 TCP:TCP通告另一端的窗口大小。 TCP套接口接收缓冲区不可能溢出,因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制,如果对方无视窗口大小而发出了超过宙口大小的数据,则接 收方TCP将丢弃它。 UDP:当接收到的数据报装不进套接口接收缓冲区时,此数据报就被丢弃。UDP是没有 流量控制的;快的发送者可以很容易地就淹没慢的接收者,导致接收方的UDP丢弃数据报。

SO_LINGER

指定函数CLOSE对面相连接的协议如何操作——当由数据残留在套接口发送缓冲区时的处理 LINGER结构

strUCt linger { int l_onoff; // 0=off, nonzero=on int l_linger; //linger time in seconds };

SO_RCVLOWAT 和SO_SNDLOWAT

每个套接口都有一个接收低潮限度和一个发送低潮限度。它们是函数select使用的, 接收低潮限度是让select返回“可读”而在套接口接收缓冲区中必须有的数据总量。 ——对于一个TCP或UDP套接口,此值缺省为1。发送低潮限度是让select返回“可写” 而在套接口发送缓冲区中必须有的可用空间。对于TCP套接口,此值常缺省为2048。 对于UDP使用低潮限度, 由于其发送缓冲区中可用空间的字节数是从不变化的,只要 UDP套接口发送缓冲区大小大于套接口的低潮限度,这样的UDP套接口就总是可写的。 UDP没有发送缓冲区,只有发送缓冲区的大小

SO_BROADCAST套接口选项

这个选项能够让我们使能或者禁止套接口的发送广播能力。只能在数据报模式下使用广播,并且还必须是支持广播消息的以太网等网络上。如果是点对点的链路上就无法办到这一点。

因为使能广播的功能必须显式执行。因此可以避免一些UDP程序无意中把广播地址当作目的地址进行发送。但是Linux在处理广播地址的时候,不是由用户来识别的,在用户空间所看到的地址格式是没有差别的。一直到内核才会识别出广播地址出来,并加以相应的处理。

数据结构

下面我们要讨论使用套接口编写程序可能要用到的数据结构。

首先是套接口描述符。一个套接口描述符只是一个整型的数值: i n t。

第一个数据结构是struct sockaddr,这个数据结构中保存着套接口的地址信息。

struct sockaddr { unsigned short sa_family; /* address family, AF_xxx */ char sa_data[14]; /* 14 bytes of protocol address */ } ;

sa_family 中可以是其他的很多值,但在这里我们把它赋值为“ AF_INET”。sa_data包括一个目的地址和一个端口地址。

你也可以使用另一个数据结构sockaddr_in,如下所示:

struct sockaddr_in { short int sin_family; /* Address family */ unsigned short int sin_port; /* Port number */ struct in_addr sin_addr; /* Internet address */ unsigned char sin_zero[8]; /* Same size as struct sockaddr */ } ;

这个数据结构使得使用其中的各个元素更为方便。要注意的是sin_zero应该使用bzero() 或者memset ( )而设置为全0。另外,一个指向sockaddr_in数据结构的指针可以投射到一个指向数据结构sockaddr的指针,反之亦然。 IP地址和如何使用IP地址


上一页 [1] [2] [3] [4] [5] 下一页 

有一系列的程序可以使你处理I P地址。

首先,你可以使用inet_addr( )程序把诸如“ 132.241.5.10“形式的I P地址转化为无符号的整型数。

ina.sin_addrs_addr = inet_addr("132.241.5.10");

如果出错,inet_addr( )程序将返回- 1。

也可以调用inet_ntoa( )把地址转换成数字和句点的形式:

printf( " % s " , inet_ntoa( ina.sin_addr ) ) ;

这将会打印出I P地址。它返回的是一个指向字符串的指针。

socket()

我们使用系统调用socket()来获得文件描述符:

#include #include int socket(int domain, int type, int protocol);

第一个参数domain设置为“AF_INET”。

第二个参数是套接口的类型:SOCK_DGRAM。

第三个参数设置为0。

系统调用socket()只返回一个套接口描述符,如果出错,则返回- 1。

bind()

一旦你有了一个套接口以后,下一步就是把套接口绑定到本地计算机的某一个端口上。但如果你只想使用connect( )则无此必要。

下面是系统调用bind( )的使用方法:

#include #include int bind(int sockfd, struct sockaddr *my_addr, int addrlen);

第一个参数sockfd 是由socket( )调用返回的套接口文件描述符。

第二个参数my_addr 是指向数据结构sockaddr的指针。数据结构sockaddr中包括了关于你的地址、端口和IP地址的信息。

第三个参数addrlen可以设置成sizeof(struct sockaddr)。下面是一个例子:

#include #include #include #define MYPORT 3490 main ( ) { int sockfd; struct sockaddr_in my_addr; //说明一个sock地址结构 sockfd = socket(AF_INET, SOCK_STREAM, 0); /* 基本的建立UDP socket,最好进行一些检查 */ my_addr.sin_family = AF_INET; /* 设定协议集,基于internet协议 */ my_addr.sin_port = htons(MYPORT); // 端口号 my_addr. sin_addr.s_addr = inet_addr("132.241.5.10");//将字符串转换成标准的地址格式 bzero(&(my_addr.sin_zero), 8); /* zero the rest of the struct */ /* don't forget your error checking for bind(): */ bind(sockfd, (struct sockaddr *)&my_addr, sizeof(struct sockaddr)); //绑定监听进程到该socket上

如果出错,bind() 也返回- 1。

如果你使用connect()系统调用,那么你不必知道你使用的端口号。当你调用connect()时,它检查套接口是否已经绑定,如果没有,它将会分配一个空闲的端口。

sendto() 和recvfrom()

因为数据报套接口并不连接到远程的主机上,所以在发送数据包之前,我们必须首先给出目的地址,请看

int sendto(int sockfd, const void *msg, int len, unsigned int flags, const struct sockaddr *to, int tolen);

除了两个参数以外,其他的参数和系统调用s e n d ( )时相同。参数t o是指向包含目的I P地址和端口号的数据结构s o c k a d d r的指针。参数t o l e n可以设置为sizeof(struct sockaddr)。

系统调用sendto( )返回实际发送的字节数,如果出错则返回- 1。

系统调用recvfrom( )的使用方法也和r e c v ( )的十分近似:

int recvfrom(int sockfd, void *buf, int len, unsigned int flags struct sockaddr *from, int *fromlen);

sockfd: 描述字

buff: 指向输入缓冲器的指针

nbytes: 读字节大小

flag: 标志:0

from :对方协议地址

addrlen: 对方协议地址长度

函数返回值: 读入数据的长度,可以为0.

参数from是指向本地计算机中包含源I P地址和端口号的数据结构sockaddr的指针。参数fromlen设置为sizeof(struct sockaddr)。

系统调用recvfrom ( )返回接收到的字节数,如果出错则返回- 1。

close() 和shutdown()

你可以使用close( )调用关闭连接的套接口文件描述符:

close(sockfd) ;

这样就不能再对此套接口做任何的读写操作了。

使用系统调用shutdown(),可有更多的控制权。它允许你在某一个方向切断通信,或者切断双方的通信:

int shutdown(int sockfd, int how);


上一页 [1] [2] [3] [4] [5] 下一页 

更多的请看:http://www.qqread.com/windows/2003/index.html

  第一个参数是你希望切断通信的套接口文件描述符。第二个参数h o w值如下:

0—Further receives are disallowed

1—Further sends are disallowed

2—Further sends and receives are disallowed (like close())

shutdown() 如果成功则返回0,如果失败则返回- 1。

客户机/服务器模式

在网络上大部分的通信都是在客户机/服务器模式下进行的。例如telnet。当你使用telnet连接到远程主机的端口23时,主机上的一个叫做telnetd的程序就开始运行。它处理所有进入的telnet连接,为你设置登录提示符等。

应当注意的是客户机/服务器模式可以使用SOCK_STREAM、SOCK_DGRAM或者任何其他的方式。例如telnet /telnetd、FTP/ftpd和bootp/bootpd。每当你使用ftp时,远程计算机都在运行一个ftpd为你服务。

一般情况下,一台机器上只有一个服务器程序,它通过使用fork( )来处理多个客户端程序的请求。最基本的处理方法是:服务器等待连接,使用accept()接受连接,调用fork( )生成一个子进程处理连接。

UDP广播模式

广播的用途之一是假定服务器主机在本地子网上,但不知道它的单播IP地址时,对它进行定位,这就是资源发现(resource discovery)。另一用途是当有多个客户和单个服务器通信时,减少局域网上数据流量。下面是几个以此为目的使用广播的因特网应用实例。

★ARP(地址解析协议,address Resolution Protocol。ARP是IPv4的一个基本组成部分,而不是一个用户应用程序。ARP在本地子网上广播一个请求:“具有IP地址a.b.c.d的系统请表明自己,并告诉我,你的硬件地址。”

★BOOTP(引导协议,Bootstrap Protocol)。客户假定有一台服务器主机在本地子网上。它以广播地址(通常是255.255.255.255,因为这是客户还不知道自己的IP地址、子网掩码或子网的受限广播地址)为目的地址发出自己的引导请求。

★NTP(网络时间协议,Network Time Protocol)。一种常见的情形是:一个NTP客户主机可能配置程使用一个或多个服务器主机的IP地址,其上面的NTP客户于是以某个频率(每64秒一次或更长)轮询这些服务器。客户采用基于服务器返送的时刻和到达服务器的往返时间的精确算法更新时钟。但在支持广播的局域网上,就不需要采用客户轮询服务器的方法,而代之以服务器以每64秒一次的频率向本地子网上的所有客户广播当前时刻。这样便可以减少网络上的数据流量。

★路由后台进程。routed是最常用的后台进程。它输出自己的路由表的方法便是局域网广播。所有其他连接到这些局域网上的路由器便可以同时接收这些路由通告,而不用每个路由器都必须配置其邻居路由器的IP地址。这个特性也被局域网上的主机用于侦听路由通告并相应更新它的路由表(许多人认为这是一种“误用”)

如果用{netid,subnetid,hostoid}。({网络Id,子网Id,主机ID})表示IPv4地址,那么有四种类型的广播地址。我们用-1表示所有比特位均为1的字段。

1、子网广播地址:{netid,subnetid,-1}。这类地址编排指定子网上的所有接口。例如,如果我们对B类地址128.7采用8位子网ID,那么128.7.6.225将是128.7.6的子网上所有接口的子网广播地址。

路由器通常不转发这类广播(TCPv2)图18.2给出了一个连接到128.7.1和128.7.6两个子网的路由器。路由器在12.7..1子网上接收到一个目的地址为210.37.6.255(另一个接口的子网广播地址)的单播IP数据报。路由器通常不向128.7.6子网转发这个数据报。有些系统具有运行转发子网广播数据报的配置选项。

2、 全部子网广播地址:{netid,-1,-1}。这类广播地址编排指定网络上的所有子网。如果说这类地址层被用过的话,那么现在已很少见了。

3、 网络广播地址:{netid,-1}。这类地址用于不进行子网划分的网络。但不进行子网划分的网络现在几乎不存在了。

4、 受限广播地址:{-1,-1,-1}或255.255.255.255。路由器从不转发目的地址为255.255.255.255的IP数据报。

在这四类广播地址中,子网广播地址是今天最常见的。但有些老系统仍然发送目的地址为255.255.255.255的数据报。还有些老系统不理解子网广播地址,他们将仅发往255.255.255.255的数据报解释为广播。


上一页 [1] [2] [3] [4] [5] 下一页 

在查看广播之前,我们应该已清楚向单播地址发送UDP数据报的步骤。图中网络的地址为192.168.0,其中8位用作子网ID,8位用作主机ID。左边主机的应用程序在一个UDP套接口上调用sendto函数,将数据报发往IP地址192.168.0.3、端口1234。UDP层附加一个UDP头部,并将UDP数据报传递到IP层。IP层给它附加一个IPv4头部,并确定其外出接口。在以太网的情况下,将调用ARP来确定与目的IP地址相应的以太网地址:08:00:22:03:ff:42。然后,将分组作为以太网帧发送出去。以太网帧的目的地址是上述48位地址。帧类型字段的值为0800,指示这是一个IPv4分组。IPv6帧类型字段的值为86dd。

中间主机的以太网接口看到该帧,并将它的目的以太网地址与自己的以太网地址(02:60:8c:2f:4e:13:)进行比较。由于二者不相等,接口便忽略该帧。因此,单播帧不会对这台主机造成任何额外开销。右边主机的以太网接口也看到该帧。当它将该帧的目的以太网地址与自己的以太网地址进行比较时,发现二者相等,接口便读入整个帧。由于帧类型字段只为0800,于是将分组放入IP输入队列。

当IP层处理该分组时,它首先将目的IP地址进行比较,由于目的地址是其中之一,于是就接受这个分组。

然后,IP层检查IPv4头部协议字段,其值对于UDP为17.于是将IP数据报传送到UDP层。

UDP层检查其目的端口(如果其UDP套接口已连接,也可能检查源端口),将数据报方到相应套接口的接收队列。如果需要,就唤醒进程,由进程读取这个新接收的数据报。

这个例子的关键点是单播IP数据报只能由目的IP地址指定的主机接收。子网上的其它主机不受任何影响。我们现在考虑一个类似的例子:同样的子网,但发送进程发送的是子网广播数据报,其地址为192.168.0.255。

当左侧的主机发送数据报时,它注意到目的IP地址是子网广播地址,于是便将它映射程48位的以太网地址ff.ff.ff.ff.ff.ff。这使得子网上的每一个以太网接口都会接收该帧。在图中右侧两台运行IPv4的主机都接收该帧。由于以太网帧类型是0800,两个主机都将数据报传递到IP层。由于目的IP地址匹配二者的广播地址,并且协议字段为17(UDP),两个主机于是都将分组上传至UDP。

最右边的主机将UDP数据报传递给绑定端口1234的应用进程。接收广播UDP数据报的应用进程不需要任何特殊的处理,它仅仅创建一个UDP套接口,并将应用的端口号捆绑到其上。(我们假设捆绑的IP地址为INADDR_ANY,这是典型的情况)但是中间的主机没有任何应用进程绑定UDP端口1234。于是主机的UDP代码丢弃这个已收到的数据报。这台主机禁止发送端口不可达的ICMP消息,因为这样做会产生广播风暴(broadcast storm):子网上许多主机机会同时产生响应,这将导致网络在几秒钟内不可用。在图中,我们也表示出了左边主机将输出数据报又递送给自己的情况,这是一种广播属性:根据定义,广播要到达子网上的所有主机,包括发送者自身。

我们还假定发送应用进程已经绑定要发送到的端口(1234),因此它将收到它发送的每个数据报的拷贝。(但是一般情况下,没有将进程捆绑数据报所发送到UDP端口的要求。)

本例也表明了广播存在地根本问题:子网上所有未参与广播应用系统的主机也必须完成对数据报的协议处理,直至在UDP层将它丢弃。所有非IP主机(例如与行 Novell IPX 的主机)也必须在链路层接收完整的帧,并在该层将它丢弃(假定这些主机不支持帧的帧类型,IPv4分组的帧类型域值为0800)。因此,以高速率产生的IP数据报的应用系统(例如音频、视频应用系统)会严重影响子网上其他主机的运行。

(出处:http://www.sheup.com)


上一页 [1] [2] [3] [4] [5] 

最右边的主机将UDP数据报传递给绑定端口1234的应用进程。接收广播UDP数据报的应用进程不需要任何特殊的处理,它仅仅创建一个UDP套接口,并将应用的端口号捆绑到其上。(我们假设捆绑的IP地址为INADDR_ANY,这是典型的情况)但是中间的主机没有任何应用进程绑定UDP端口1234。于是主机的UDP代码丢弃这个已收到的数据报。这台主机禁止发送端口不可达的ICMP消息,因为这样做会产生广播风暴(broadcast storm):子网上许多主机机会同时产生响应,这将导致网络在几秒钟内不可用。在图中,我们也表示出了左边主机将输出数据报又递送给自己的情况,这是一种广播属性:根据定义,广播要到达子网上的所有主机,包括发送者自身。

我们还假定发送应用进程已经绑定要发送到的端口(1234),因此它将收到它发送的每个数据报的拷贝。(但是一般情况下,没有将进程捆绑数据报所发送到UDP端口的要求。)

本例也表明了广播存在地根本问题:子网上所有未参与广播应用系统的主机也必须完成对数据报的协议处理,直至在UDP层将它丢弃。所有非IP主机(例如与行 Novell IPX 的主机)也必须在链路层接收完整的帧,并在该层将它丢弃(假定这些主机不支持帧的帧类型,IPv4分组的帧类型域值为0800)。因此,以高速率产生的IP数据报的应用系统(例如音频、视频应用系统)会严重影响子网上其他主机的运行。

(出处:http://www.sheup.com/)


上一页 [1] [2] [3] [4] [5] [6]