如何在 C 语言中获取发送者的 UDP 端口？
我在 Linux 下用 C 编写了以下典型代码来获取 UDP 数据：
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
mysock.sin_family = AF_INET;
mysock.sin_addr.s_addr = INADDR_ANY;
mysock.sin_port = my_port;
bind(sock, &mysock, sizeof(mysock);
recvfrom(sock, buf, PKTSZ, 0, &client, len);
上述所有代码都有效，但现在我需要找出发送者的 UDP 端口，是否有一个结构或系统调用可以用来检索此类信息我收到 UDP 数据包？
谢谢
I have the following typical code in C under Linux to get UDP data:
sock = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDP);
mysock.sin_family = AF_INET;
mysock.sin_addr.s_addr = INADDR_ANY;
mysock.sin_port = my_port;
bind(sock, &mysock, sizeof(mysock);
recvfrom(sock, buf, PKTSZ, 0, &client, len);
All the above code works, but now I have a need to find out the sender's UDP port, is there a structure or system call I can use to retrieve such info when I receive a UDP packet ?
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
发送者套接字地址存储在代码的 client 变量中。 要访问发送者端口，请使用 sockaddr_in 而不是 sockaddr。 示例：
参考文献：
Beej 网络编程指南 和 MSDN
The senders socket address is stored in the client variable of your code. To access the senders port use sockaddr_in instead of sockaddr. Example:
References:
Beej's Guide to Network Programming and MSDN
recvfrom() 应该在第五个参数（struct sockaddr*）中将其返回给您。
编辑：
使用类似这样的
client.sin_port应该是发送者的端口。recvfrom() is supposed to return that to you in the fifth argument (struct sockaddr*).
EDIT:
Use something like this
client.sin_portshould be the sender's port.UDP 发送方端口将是暂时的。 我认为除了报告之外，您不能将其用于任何其他用途。
UDP sender port would be transient. I don't think you could use that for anything other than for reporting.
第五个参数可以转换为struct sockaddr_in，其中sin_port是远程端口号。
The fifth argument can be cast to
struct sockaddr_in, and theresin_portis the remote port number.将客户端强制转换为 sockaddr_in 解决了我的问题。
Casting the client to sockaddr_in solves my problem.
是的！ 首先记住 ntohs()！ 直到我使用程序员的计算器，我才意识到它存储为 BigEndian 15B3，而不是可能的临时端口 B315！
Yes! Remember the ntohs() above all! It wasn't until I used the programmer's calculator that I realized it WAS stored as BigEndian 15B3, not the presumably ephemeral port B315!