2

サーバー:
vxworks 6.3
は通常のソケット、バインド、リッスンを呼び出し、次に:

for (;;)
{
  client = accept(sfd,NULL,NULL);
  // pass client to worker thread
}

client:サーバーに接続するための
.NET 2.0
TcpClient コンストラクター。次のように、文字列ホスト名と int ポートを使用します。 

TcpClient client = new TcpClient(server_ip, port);

これは、サーバーが Windows (ネイティブ C++) でコンパイルおよび実行されている場合に正常に機能します。

断続的に、TcpClient のコンストラクターは例外をスローせずにインスタンスを返しますが、vxWorks の受け入れ呼び出しはクライアント fd を返しません。tcpstatShow は、受け入れが発生しなかったことを示します。

TcpClient コンストラクター (「Connect」を呼び出す) がインスタンスを返す可能性があるのに、サーバーでの accept 呼び出しが返されないのはなぜでしょうか? これは、システムがバックグラウンドで実行していることに関連しているようです。クライアントが接続を試みたときに、サーバーがフラッシュまたは NFS 共有にデータを永続化するためにビジーである場合に、この症状が発生する可能性が高くなります。もありません。

私は受け入れを実行しているスレッドの優先度を調整しようとし
ました。「リッスン」でキューのサイズを調べました。十分です。
利用可能なファイル記述子の総数は十分なはずです（ただし、これはまだ検証されていません。朝一番に）

4

4 に答える 4

1

ワイヤーで何が起こっているのかをwireshark/netmonに投稿することは可能ですか？

于 2010-06-17T04:41:27.397 に答える
0

サーバーのaccept()呼び出しが間違っているようです。accept()私が知っているPOSIX呼び出しには、次のものがあります。

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

呼び出しが機能する場合に書き込まれる必須のポインタはどこに*addrありますか。実際、呼び出しの失敗状態の1つは次のとおりです。

[EFAULT]    The address parameter is not in a writable part of the user address space.

私はWindowsソケットプログラミングを行っていませんが、POSIXに準拠していることを理解しています。また、Beejのガイドにはaccept（）のWindowsの例外については記載されていないため、これは引き続き適用されます。やや関連性がありますが、Pythonのaccept（）呼び出しもフィールドを「返します」address（PythonはCネットワーキングAPIをエミュレートするために最善を尽くしたので、ある程度意味があります）。

サーバーでの呼び出し後に、が設定されているかどうかを確認errnoして使用することをお勧めします（またはに設定されているため、記述子が不足した場合にも通知されます）perroraccept[EFAULT]errno[EMFILE][ENFILE]

それが問題であることが判明しない場合は、サーバーまたはクライアントとしてncatを使用して、さらに調査します。-vv接続がいつ行われるか、何が送信されるかなどを正確に知りたいので、一緒に実行します。

于 2010-06-19T10:31:30.197 に答える
0

サーバーを別のポートにバインドして、そこで受け入れられるかどうかを確認することは可能ですか? クライアントが返された場合、サーバー上の何かから受け入れられているように聞こえます。vxworks についてはわかりませんが、Windows では常に 1000 未満のものにバインドしないようにする必要があります。

于 2010-06-18T14:31:55.067 に答える
0

多くの理由が考えられますが、サーバー側とクライアント側からより多くの情報を取得できない限りわかりません。エラーは発生しますか？TCP/IP エラーのリストは、 Windows ソケット エラーで確認できます。サーバー側では、例外をキャッチしていますか? エラーが発生した後、接続を (1 秒ほど待って) 閉じてみてはいかがでしょうか?

于 2010-06-15T07:01:39.757 に答える