linuxudp編程

『壹』 在linux 上，編寫一個每秒接收 100萬UDP數據包的程序究竟有多難

首先，我們假設：
測量每秒的數據包(pps)比測量每秒位元組數(Bps)更有意思。您可以通過更好的管道輸送以及發送更長數據包來獲取更高的Bps。而相比之下，提高pps要困難得多。
因為我們對pps感興趣，我們的實驗將使用較短的 UDP 消息。准確來說是 32 位元組的 UDP 負載，這相當於乙太網層的 74 位元組。
在實驗中，我們將使用兩個物理伺服器：「接收器」和「發送器」。
它們都有兩個六核2 GHz的 Xeon處理器。每個伺服器都啟用了 24 個處理器的超線程(HT)，有 Solarflare 的 10G 多隊列網卡，有 11 個接收隊列配置。稍後將詳細介紹。
測試程序的源代碼分別是：udpsender、udpreceiver。
預備知識
我們使用4321作為UDP數據包的埠，在開始之前，我們必須確保傳輸不會被iptables干擾：

Shell

receiver$ iptables -I INPUT 1 -p udp --dport 4321 -j ACCEPT

receiver$ iptables -t raw -I PREROUTING 1 -p udp --dport 4321 -j NOTRACK

為了後面測試方便，我們顯式地定義IP地址：

Shell

receiver$ for i in `seq 1 20`; do

ip addr add 192.168.254.$i/24 dev eth2;

done

sender$ ip addr add 192.168.254.30/24 dev eth3

1. 簡單的方法
開始我們做一些最簡單的試驗。通過簡單地發送和接收，有多少包將會被傳送？
模擬發送者的偽代碼：

Python

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

fd.bind(("0.0.0.0", 65400)) # select source port to rece nondeterminism

fd.connect(("192.168.254.1", 4321))

while True:

fd.sendmmsg(["x00" * 32] * 1024)

因為我們使用了常見的系統調用的send，所以效率不會很高。上下文切換到內核代價很高所以最好避免它。幸運地是，最近Linux加入了一個方便的系統調用叫sendmmsg。它允許我們在一次調用時，發送很多的數據包。那我們就一次發1024個數據包。
模擬接受者的偽代碼：

Python

fd = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
fd.bind(("0.0.0.0", 4321))
while True:
packets = [None] * 1024
fd.recvmmsg(packets, MSG_WAITFORONE)

同樣地，recvmmsg 也是相對於常見的 recv 更有效的一版系統調用。
讓我們試試吧：

Shell

sender$ ./udpsender 192.168.254.1:4321
receiver$ ./udpreceiver1 0.0.0.0:4321
0.352M pps 10.730MiB / 90.010Mb
0.284M pps 8.655MiB / 72.603Mb
0.262M pps 7.991MiB / 67.033Mb
0.199M pps 6.081MiB / 51.013Mb
0.195M pps 5.956MiB / 49.966Mb
0.199M pps 6.060MiB / 50.836Mb
0.200M pps 6.097MiB / 51.147Mb
0.197M pps 6.021MiB / 50.509Mb

測試發現，運用最簡單的方式可以實現 197k – 350k pps。看起來還不錯嘛，但不幸的是，很不穩定啊，這是因為內核在核之間交換我們的程序，那我們把進程附在 CPU 上將會有所幫助

Shell

sender$ taskset -c 1 ./udpsender 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.362M pps 11.058MiB / 92.760Mb
0.374M pps 11.411MiB / 95.723Mb
0.369M pps 11.252MiB / 94.389Mb
0.370M pps 11.289MiB / 94.696Mb
0.365M pps 11.152MiB / 93.552Mb
0.360M pps 10.971MiB / 92.033Mb

現在內核調度器將進程運行在特定的CPU上，這提高了處理器緩存，使數據更加一致，這就是我們想要的啊！
2. 發送更多的數據包
雖然 370k pps 對於簡單的程序來說已經很不錯了，但是離我們 1Mpps 的目標還有些距離。為了接收更多，首先我們必須發送更多的包。那我們用獨立的兩個線程發送，如何呢：

Shell

sender$ taskset -c 1,2 ./udpsender
192.168.254.1:4321 192.168.254.1:4321
receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.349M pps 10.651MiB / 89.343Mb
0.354M pps 10.815MiB / 90.724Mb
0.354M pps 10.806MiB / 90.646Mb
0.354M pps 10.811MiB / 90.690Mb

接收一端的數據沒有增加，ethtool –S 命令將顯示數據包實際上都去哪兒了：

Shell

receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx_nodesc_drop_cnt: 451.3k/s
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 0.5/s
rx-4.rx_packets: 355.2k/s
rx-5.rx_packets: 0.0/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s

通過這些統計，NIC 顯示 4 號 RX 隊列已經成功地傳輸大約 350Kpps。rx_nodesc_drop_cnt 是 Solarflare 特有的計數器，表明NIC發送到內核未能實現發送 450kpps。
有時候，這些數據包沒有被發送的原因不是很清晰，然而在我們這種情境下卻很清楚：4號RX隊列發送數據包到4號CPU，然而4號CPU已經忙不過來了，因為它最忙也只能讀350kpps。在htop中顯示為：

多隊列 NIC 速成課程
從歷史上看，網卡擁有單個RX隊列，用於硬體和內核之間傳遞數據包。這樣的設計有一個明顯的限制，就是不可能比單個CPU處理更多的數據包。
為了利用多核系統，NIC開始支持多個RX隊列。這種設計很簡單：每個RX隊列被附到分開的CPU上，因此，把包送到所有的RX隊列網卡可以利用所有的CPU。但是又產生了另一個問題：對於一個數據包，NIC怎麼決定把它發送到哪一個RX隊列？

用 Round-robin 的方式來平衡是不能接受的，因為這有可能導致單個連接中數據包的重排序。另一種方法是使用數據包的hash值來決定RX號碼。Hash值通常由一個元組（源IP，目標IP，源port，目標port）計算而來。這確保了從一個流產生的包將最終在完全相同的RX隊列，並且不可能在一個流中重排包。
在我們的例子中，hash值可能是這樣的：

Shell

1

RX_queue_number = hash('192.168.254.30', '192.168.254.1', 65400, 4321) % number_of_queues

多隊列 hash 演算法
Hash演算法通過ethtool配置，設置如下：

Shell

receiver$ ethtool -n eth2 rx-flow-hash udp4
UDP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA

對於IPv4 UDP數據包，NIC將hash(源 IP,目標 IP)地址。即

Shell

1

RX_queue_number = hash('192.168.254.30', '192.168.254.1') % number_of_queues

這是相當有限的，因為它忽略了埠號。很多NIC允許自定義hash。再一次，使用ethtool我們可以選擇元組(源 IP、目標 IP、源port、目標port)生成hash值。

Shell

receiver$ ethtool -N eth2 rx-flow-hash udp4 sdfn
Cannot change RX network flow hashing options: Operation not supported

不幸地是，我們的NIC不支持自定義，我們只能選用(源 IP、目的 IP) 生成hash。
NUMA性能報告
到目前為止，我們所有的數據包都流向一個RX隊列，並且一個CPU。我們可以借這個機會為基準來衡量不同CPU的性能。在我們設置為接收方的主機上有兩個單獨的處理器，每一個都是一個不同的NUMA節點。
在我們設置中，可以將單線程接收者依附到四個CPU中的一個，四個選項如下：
另一個CPU上運行接收器，但將相同的NUMA節點作為RX隊列。性能如上面我們看到的，大約是360 kpps。
將運行接收器的同一 CPU 作為RX隊列，我們可以得到大約430 kpps。但這樣也會有很高的不穩定性，如果NIC被數據包所淹沒，性能將下降到零。
當接收器運行在HT對應的處理RX隊列的CPU之上，性能是通常的一半，大約在200kpps左右。
接收器在一個不同的NUMA節點而不是RX隊列的CPU上，性能大約是330 kpps。但是數字會不太一致。
雖然運行在一個不同的NUMA節點上有10%的代價，聽起來可能不算太壞，但隨著規模的變大，問題只會變得更糟。在一些測試中，每個核只能發出250 kpps，在所有跨NUMA測試中，這種不穩定是很糟糕。跨NUMA節點的性能損失，在更高的吞吐量上更明顯。在一次測試時，發現在一個壞掉的NUMA節點上運行接收器，性能下降有4倍。
3.多接收IP
因為我們NIC上hash演算法的限制，通過RX隊列分配數據包的唯一方法是利用多個IP地址。下面是如何將數據包發到不同的目的IP：

1

sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321

ethtool 證實了數據包流向了不同的 RX 隊列：

Shell

receiver$ watch 'sudo ethtool -S eth2 |grep rx'
rx-0.rx_packets: 8.0/s
rx-1.rx_packets: 0.0/s
rx-2.rx_packets: 0.0/s
rx-3.rx_packets: 355.2k/s
rx-4.rx_packets: 0.5/s
rx-5.rx_packets: 297.0k/s
rx-6.rx_packets: 0.0/s
rx-7.rx_packets: 0.5/s
rx-8.rx_packets: 0.0/s
rx-9.rx_packets: 0.0/s
rx-10.rx_packets: 0.0/s

接收部分：

Shell

receiver$ taskset -c 1 ./udpreceiver1 0.0.0.0:4321
0.609M pps 18.599MiB / 156.019Mb
0.657M pps 20.039MiB / 168.102Mb
0.649M pps 19.803MiB / 166.120Mb

萬歲！有兩個核忙於處理RX隊列，第三運行應用程序時，可以達到大約650 kpps !
我們可以通過發送數據到三或四個RX隊列來增加這個數值，但是很快這個應用就會有另一個瓶頸。這一次rx_nodesc_drop_cnt沒有增加，但是netstat接收到了如下錯誤：

Shell

receiver$ watch 'netstat -s --udp'
Udp:
437.0k/s packets received
0.0/s packets to unknown port received.
386.9k/s packet receive errors
0.0/s packets sent
RcvbufErrors: 123.8k/s
SndbufErrors: 0
InCsumErrors: 0

這意味著雖然NIC能夠將數據包發送到內核，但是內核不能將數據包發給應用程序。在我們的case中，只能提供440 kpps，其餘的390 kpps + 123 kpps的下降是由於應用程序接收它們不夠快。
4.多線程接收
我們需要擴展接收者應用程序。最簡單的方式是利用多線程接收，但是不管用：

Shell

sender$ taskset -c 1,2 ./udpsender 192.168.254.1:4321 192.168.254.2:4321
receiver$ taskset -c 1,2 ./udpreceiver1 0.0.0.0:4321 2
0.495M pps 15.108MiB / 126.733Mb
0.480M pps 14.636MiB / 122.775Mb
0.461M pps 14.071MiB / 118.038Mb
0.486M pps 14.820MiB / 124.322Mb

接收性能較於單個線程下降了，這是由UDP接收緩沖區那邊的鎖競爭導致的。由於兩個線程使用相同的套接字描述符，它們花費過多的時間在UDP接收緩沖區的鎖競爭。這篇論文詳細描述了這一問題。
看來使用多線程從一個描述符接收，並不是最優方案。
5. SO_REUSEPORT
幸運地是，最近有一個解決方案添加到 Linux 了 —— SO_REUSEPORT 標志位（flag）。當這個標志位設置在一個套接字描述符上時，Linux將允許許多進程綁定到相同的埠，事實上，任何數量的進程將允許綁定上去，負載也會均衡分布。
有了SO_REUSEPORT，每一個進程都有一個獨立的socket描述符。因此每一個都會擁有一個專用的UDP接收緩沖區。這樣就避免了以前遇到的競爭問題：

Shell

1
2
3
4

receiver$ taskset -c 1,2,3,4 ./udpreceiver1 0.0.0.0:4321 4 1
1.114M pps 34.007MiB / 285.271Mb
1.147M pps 34.990MiB / 293.518Mb
1.126M pps 34.374MiB / 288.354Mb

現在更加喜歡了，吞吐量很不錯嘛！
更多的調查顯示還有進一步改進的空間。即使我們開始4個接收線程，負載也會不均勻地分布：

兩個進程接收了所有的工作，而另外兩個根本沒有數據包。這是因為hash沖突，但是這次是在SO_REUSEPORT層。
結束語
我做了一些進一步的測試，完全一致的RX隊列，接收線程在單個NUMA節點可以達到1.4Mpps。在不同的NUMA節點上運行接收者會導致這個數字做多下降到1Mpps。
總之，如果你想要一個完美的性能，你需要做下面這些：
確保流量均勻分布在許多RX隊列和SO_REUSEPORT進程上。在實踐中，只要有大量的連接(或流動)，負載通常是分布式的。
需要有足夠的CPU容量去從內核上獲取數據包。
To make the things harder, both RX queues and receiver processes should be on a single NUMA node.
為了使事情更加穩定，RX隊列和接收進程都應該在單個NUMA節點上。
雖然我們已經表明，在一台Linux機器上接收1Mpps在技術上是可行的，但是應用程序將不會對收到的數據包做任何實際處理——甚至連看都不看內容的流量。別太指望這樣的性能，因為對於任何實際應用並沒有太大用處。

『貳』 基於Linux的遠程指令系統（使用udp而不是tcp）

一. Linux下UDP編程框架

使用UDP進行程序設計可以分為客戶端和伺服器端兩部分。
1.伺服器端程序包括：
? 建立套接字
? 將套接字地址結構進行綁定
? 讀寫數據
? 關閉套接字
2.客戶端程序包括：
? 建立套接字
? 讀寫數據
? 關閉套接字
3.伺服器端和客戶端程序之間的差別
伺服器端和客戶端兩個流程之間的主要差別在於對地址的綁定函數（bind()函數），而客戶端可以不用進行地址和埠的綁定操作。

二.Linux中UDP套接字函數

從圖可知，UDP協議的服務端程序設計的流程分為套接字建立，套接字與地址結構進行綁定，收發數據，關閉套接字;客戶端程序流程為套接字建立，收發數據，關閉套接字等過程。它們分別對應socket(),bind(),sendto(),recvfrom(),和close()函數。
網路程序通過調用socket（）函數，會返回一個用於通信的套接字描述符。Linux應用程序在執行任何形式的I/O操作的時候，程序是在讀或者寫一個文件描述符。因此，可以把創建的套接字描述符看成普通的描述符來操作，並通過讀寫套接字描述符來實現網路之間的數據交流。
1. socket
1> 函數原型:
int socket(int domain,int type,int protocol)
2> 函數功能：
函數socket()用於創建一個套接字描述符。
3> 形參：
? domain:用於指定創建套接字所使用的協議族，在頭文件
中定義。
常見的協議族如下：
AF_UNIX:創建只在本機內進行通信的套接字。
AF_INET:使用IPv4 TCP/IP協議
AF_INET6:使用IPv6 TCP/IP協議
說明：
AF_UNIX只能用於單一的UNIX系統進程間通信，而AF_INET是針對Interne的，因而可以允許在遠程主機之間通信。一般把它賦為AF_INET。
? type:指明套接的類型，對應的參數如下
SOCK_STREAM:創建TCP流套接字
SOCK_DGRAM:創建UDP數據報套接字
SOCK_RAW:創建原始套接字
? protocol:
參數protocol通常設置為0，表示通過參數domain指定的協議族和參數type指定的套接字類型來確定使用的協議。當為原始套接字時，系統無法唯一的確定協議，此時就需要使用使用該參數指定所使用的協議。
4> 返回值：執行成功後返回一個新創建的套接字；若有錯誤發生則返回一個-1，錯誤代碼存入errno中。
5> 舉例：調用socket函數創建一個UDP套接字
int sock_fd;
sock_fd = socket(AF_INET,SOCK_DGRAM,0);
if(sock_fd < 0){
perror(「socket」);
exit(1);
}
2. bind
1> 函數原型：
int bind(int sockfd,struct sockaddr *my_addr,socklen_taddrlen)
2> 函數功能
函數bind()的作用是將一個套接字文件描述符與一個本地地址綁定在一起。
3> 形參：
? sockfd:sockfd是調用socket函數返回的文件描述符；
? addrlen是sockaddr結構的長度。
? my_addr: 是一個指向sockaddr結構的指針，它保存著本地套接字的地址（即埠和IP地址）信息。不過由於系統兼容性的問題，一般不使用這個結構，而使用另外一個結構(struct sockaddr_in)來代替
4> 套接字地址結構：
(1)structsockaddr:
結構struct sockaddr定義了一種通用的套接字地址，它在
Linux/socket.h 中定義。
struct sockaddr{
unsigned short sa_family;/*地址類型，AF_XXX*/
char sa_data[14];/*14位元組的協議地址*/
}
a. sin_family：表示地址類型，對於使用TCP/IP協議進行的網路編程，該值只能是AF_INET.
b. sa_data：存儲具體的協議地址。
(2)sockaddr_in
每種協議族都有自己的協議地址格式，TCP/IP協議組的地址格式為結構體struct sockaddr_in,它在netinet/in.h頭文件中定義。
struct sockaddr_in{
unsigned short sin_family;/*地址類型*/
unsigned short sin_port;/*埠號*/
struct in_addr sin_addr;/*IP地址*/
unsigned char sin_zero[8];/*填充位元組，一般賦值為0*/
}
a. sin_family：表示地址類型，對於使用TCP/IP協議進行的網路編程，該值只能是AF_INET.
b. sin_port:是埠號
c. sin_addr:用來存儲32位的IP地址。
d. 數組sin_zero為填充欄位，一般賦值為0.
e. structin_addr的定義如下：
struct in_addr{
unsignedlong s_addr;
}
結構體sockaddr的長度為16位元組，結構體sockaddr_in的長度為16位元組。可以將參數my_addr的sin_addr設置為INADDR_ANY而不是某個確定的IP地址就可以綁定到任何網路介面。對於只有一IP地址的計算機，INADDR_ANY對應的就是它的IP地址；對於多宿主主機(擁有多個網卡)，INADDR_ANY表示本伺服器程序將處理來自所有網路介面上相應埠的連接請求
5> 返回值：
函數成功後返回0，當有錯誤發生時則返回-1，錯誤代碼存入errno中。
6>舉例：調用socket函數創建一個UDP套接字
struct sockaddr_in addr_serv,addr_client;/*本地的地址信息*/
memset(&serv_addr,0,sizeof(struct sockaddr_in));
addr_serv.sin_family = AF_INET;/*協議族*/
addr_serv.sin_port = htons(SERV_PORT);/*本地埠號*/
addr_serv.sin_addr.s_addr = htonl(INADDR_ANY); /*任意本地地址*/
/*套接字綁定*/
if(bind(sock_fd,(struct sockaddr *)&addr_serv),sizeof(structsockaddr_in)) <0)
{
perror(「bind」);
exit(1);
}
3.close
1>函數原型：
int close(intfd);
2>函數功能：
函數close用來關閉一個套接字描述符。
3>函數形參：
? 參數fd為一個套接字描述符。
4>返回值：
執行成功返回0，出錯則返回-1.錯誤代碼存入errno中。
說明：
以上三個函數中，前兩個要包含頭文件
#include
#include
後一個包含：
#include
4.sendto
1>函數原型：
#include
#include
ssize_t sendo(ints,const void *msg,size_t len,int flags,const struct sockaddr *to,socklen_ttolen);
2>函數功能：
向目標主機發送消息
3>函數形參：
? s:套接字描述符。
? *msg:發送緩沖區
? len:待發送數據的長度
? flags:控制選項，一般設置為0或取下面的值
(1)MSG_OOB:在指定的套接字上發送帶外數據(out-of-band data),該類型的套接字必須支持帶外數據（eg:SOCK_STREAM）.
(2)MSG_DONTROUTE:通過最直接的路徑發送數據，而忽略下層協議的路由設置。
? to:用於指定目的地址
? tolen:目的地址的長度。
4>函數返回值：
執行成功後返回實際發送數據的位元組數，出錯返回-1，錯誤代碼存入errno中。
5>函數舉例：
char send_buf[BUFFERSIZE];
struct sockaddr_in addr_client;

memset(&addr_client,0,sizeof(struct sockaddr_in));
addr_client.sin_family = AF_INET;
addr_client.sin_port = htons(DEST_PORT);
if(inet_aton(「172.17.242.131」,&addr_client.sin_addr)<0){
perror(「inet_aton」);
exit(1);
}
if(sendto(sock_fd,send_buf,len,0,(strut sockaddr*)&addr_client,sizeof(struct sockaddr_in)) <0){
perror(「sendto」);
exit(1);
}
5.recvfrom
1>函數原型：
#include
#include
ssize_t recvfrom(int s,void *buf,size_t len,intflags,struct sockaddr *from,socklen_t *fromlen);
2>函數功能：接收數據
3>函數形參：
? int s:套接字描述符
? buf:指向接收緩沖區，接收到的數據將放在這個指針所指向的內存空間。
? len:指定了緩沖區的大小。
? flags:控制選項,一般設置為0或取以下值
(1)MSG_OOB:請求接收帶外數據
(2)MSG_PEEK:只查看數據而不讀出
(3)MSG_WAITALL:只在接收緩沖區時才返回。
? *from:保存了接收數據報的源地址。
? *fromlen:參數fromlen在調用recvfrom前為參數from的長度，調用recvfrom後將保存from的實際大小。
4>函數返回值：
執行成功後返回實際接收到數據的位元組數，出錯時則返回-1，錯誤代碼存入errno中。
5>函數實例：
char recv_buf[BUFFERSIZE];
struct sockaddr_in addr_client;
int src_len;
src_len = sizeof(struct sockaddr_in);
int src_len;
src_len = sizeof(struct sockaddr_in);
if(recvfrom(sock_fd,recv_buf,sizeof(recv_buf),0,(structsockaddr *)&src_addr,&src_len)<0){
perror(「again_recvfrom」);
exit(1);
}
三.UDP編程實例

客戶端向伺服器發送字元串Hello tiger,伺服器接收到數據後將接收到字元串發送回客戶端。

1.伺服器端程序
1 #include
2 #include
3 #include
4 #include
5 #include
6 #include
7 #include
8 #include
9
10 #define SERV_PORT 3000
11
12 int main()
13 {
14 int sock_fd; //套接子描述符號
15 int recv_num;
16 int send_num;
17 int client_len;
18 char recv_buf[20];
19 struct sockaddr_in addr_serv;
20 struct sockaddr_in addr_client;//伺服器和客戶端地址
21 sock_fd = socket(AF_INET,SOCK_DGRAM,0);
22 if(sock_fd < 0){
23 perror("socket");
24 exit(1);
25 } else{
26
27 printf("sock sucessful\n");
28 }
29 //初始化伺服器斷地址
30 memset(&addr_serv,0,sizeof(struct sockaddr_in));
31 addr_serv.sin_family = AF_INET;//協議族
32 addr_serv.sin_port = htons(SERV_PORT);
33 addr_serv.sin_addr.s_addr = htonl(INADDR_ANY);//任意本地址
34
35 client_len = sizeof(struct sockaddr_in);
36 /*綁定套接子*/
37 if(bind(sock_fd,(struct sockaddr *)&addr_serv,sizeof(struct sockaddr_in))<0 ){
38 perror("bind");
39 exit(1);

40 } else{
41
42 printf("bind sucess\n");
43 }
44 while(1){
45 printf("begin recv:\n");
46 recv_num = recvfrom(sock_fd,recv_buf,sizeof(recv_buf),0,(struct sockaddr *)&addr_client,&client_len);
47 if(recv_num < 0){
48 printf("bad\n");
49 perror("again recvfrom");
50 exit(1);
51 } else{
52 recv_buf[recv_num]='\0';
53 printf("recv sucess:%s\n",recv_buf);
54 }
55 printf("begin send:\n");
56 send_num = sendto(sock_fd,recv_buf,recv_num,0,(struct sockaddr *)&addr_client,client_len);
57 if(send_num < 0){
58 perror("sendto");
59 exit(1);
60 } else{
61 printf("send sucessful\n");
62 }
63 }
64 close(sock_fd);
65 return 0;
66 }

2.客戶端程序
1 #include
2 #include
3 #include
4 #include
5 #include
6
7 #include
8 #include
9 #include
10
11 #define DEST_PORT 3000
12 #define DSET_IP_ADDRESS "192.168.1.103"
13
14 int main()
15 {
16 int sock_fd;/*套接字文件描述符*/
17 int send_num;
18 int recv_num;
19 int dest_len;
20 char send_buf[20]={"hello tiger"};
21 char recv_buf[20];
22 struct sockaddr_in addr_serv;/*服務端地址，客戶端地址*/
23
24 sock_fd = socket(AF_INET,SOCK_DGRAM,0);//創建套接子
25 //初始化伺服器端地址
26 memset(&addr_serv,0,sizeof(addr_serv));
27 addr_serv.sin_family = AF_INET;
28 addr_serv.sin_addr.s_addr = inet_addr(DSET_IP_ADDRESS);
29 addr_serv.sin_port = htons(DEST_PORT);
30
31 dest_len = sizeof(struct sockaddr_in);
32 printf("begin send:\n");
33 send_num = sendto(sock_fd,send_buf,sizeof(send_buf),0,(struct sockaddr *)&addr_serv,dest_len);
34 if(send_num < 0){
35 perror("sendto");
36 exit(1);
37 } else{
38
39 printf("send sucessful:%s\n",send_buf);

40 }
41 recv_num = recvfrom(sock_fd,recv_buf,sizeof(recv_buf),0,(struct sockaddr *)&addr_serv,&dest_len);
42 if(recv_num <0 ){
43
44 perror("recv_from");
45 exit(1);
46 } else{
47 printf("recv sucessful\n");
48 }
49 recv_buf[recv_num]='\0';
50 printf("the receive:%s\n",recv_buf);
51 close(sock_fd);
52 return 0;
53 }

『叄』 linux socket編程之udp廣播 假設，兩台pc網線直連，a電腦ip設置為192.168.

不可以，必須是同一個網段，然後廣播地址可以是192.168.1.255或者255.255.255.255