我有一个服务器而不是一个“命令处理程序”进程。它通过 UDP 接收消息,并通过它发布的 API(无论该进程使用何种 IPC 机制)与该进程通信,将要完成的工作委托(delegate)给另一个进程。我们的系统有几个协作进程。然后,该 API 调用的结果从命令处理程序进程发送回客户端。
一个命令是控制从另一个进程生成到客户端的数据流(“连接”消息)。
这应该有效吗?我将客户端的 IP 地址和端口号发送到另一个进程,该进程创建了一个新的套接字,并执行了一个 sendto...我已经跟踪了代码,一切看起来都很好,但客户端仍然被阻止接收...我知道如果我从命令处理程序执行 sendto,它会得到响应,但不是来自新套接字。
下面是一些示例代码:
#define LEN 10000
char buffer[LEN];
int sfd, nsfd, bread, addrsize;
struct sockaddr_in addr;
addrsize = sizeof (struct sockaddr_in);
server.sin_family = AF_INET;
server.sin_port = htons(5200);
server.sin_addr.s_addr = INADDR_ANY;
sfd = socket (AF_INET, SOCK_DGRAM, IPPROTO_UDP);
bind (sfd, (struct sockaddr*)&server, addrsize);
bread = recvfrom(sfd, buffer, LEN, 0, &addr, &addrsize);
/* send IP address and port number through the API to another process */
/* in that other process, I do something like this...addr has the IP
* address and port in it from above: */
nsfd = socket (AF_INET, SOCK_DGRAM, IPROTO_UDP);
sendto(nsfd, buff, bread, 0, &addr, sizeof(addr));
所以请帮忙!
最佳答案
您的客户端(或介于两者之间的防火墙)可能会因为接收到来自与发送请求的源端口不同的源端口的响应而感到困惑(因为操作系统只会为新套接字选择一个随机源端口)。
解决此问题的一种方法是在服务器中使用 SO_REUSEADDR 套接字选项,并在发送回复时明确绑定(bind)到正确的端口。但这也会产生不良的副作用,即 UDP 请求可能会被重定向到其他进程之一而不是服务器。
另一种选择(如果您使用的是 Unix/Linux)是通过 unix 域套接字(通过 sendmsg 和辅助数据)将服务器套接字传递给其他进程。
关于c++ - 从不同进程通过套接字 (UDP) 回复客户端,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/752492/