0

「コマンドハンドラー」プロセスよりもサーバーがあります。UDP 経由でメッセージを受信し、発行された API (プロセスが使用する IPC メカニズムに関係なく) を介してそのプロセスと通信することにより、別のプロセスに実行する作業を委任します。私たちのシステムには、いくつかの協調プロセスがあります。次に、その API 呼び出しの結果が、コマンド ハンドラー プロセスからクライアントに返されます。

1 つのコマンドは、別のプロセスからクライアントに生成されるデータ ストリームを制御することです (「接続」メッセージ)。

これは機能するはずですか？クライアントの 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));

だから助けてください！

4

2 に答える 2

1

クライアント (またはその間のファイアウォール) は、要求を送信したソース ポートとは異なるソース ポートから応答を受信することで混乱する可能性があります (OS は新しいソケットのランダムなソース ポートを選択するため)。

これを回避する 1 つの方法は、サーバーで SO_REUSEADDR ソケット オプションを使用し、応答を送信するときに正しいポートに明示的にバインドすることです。ただし、これには、UDP 要求がサーバーではなく他のプロセスの 1 つにリダイレクトされる可能性があるという望ましくない副作用もあります。

別のオプション (Unix/Linux を使用している場合) は、サーバー ソケットを UNIX ドメイン ソケットを介して (sendmsg および補助データを介して) 他のプロセスに渡すことです。

于 2009-04-18T13:59:48.000 に答える
1

次のようなエラーリターンをテストする必要があります

if((nsfd = socket (AF_INET, SOCK_DGRAM, IPROTO_UDP)) < 0} {
    perror("at socket open");
    // I'd call exit here, probably
}
if(sendto(nsfd, buff, bread, 0, &addr, sizeof(addr) < 0){
    perror("At sendto");
}

ここに素晴らしいチュートリアルの例があります。

于 2009-04-15T16:35:09.403 に答える