問題タブ [sockets]

現在、当社の製品の 1 つにある FTP アップロード機能に関する顧客の問題をデバッグしようとしています。この機能により、顧客はファイル (< 1MB) を中央の FTP サーバーにアップロードして、さらに処理することができます。FTP クライアント コードは、VB.NET で社内で作成されました。

顧客は、300KB から 500KB の範囲のファイルをアップロードしようとすると、「接続がリモート ホストによって強制的に閉じられました」というエラーが表示されると報告しています。ただし、社内でこれをはるかに大きなファイル (比較的言えば)、つまり 3MB 以上でテストしましたが、このエラーは発生しませんでした。クライアントが同じ FTP ログオン資格情報を使用して接続するのと同じ FTP サーバーにアップロードしました。唯一の違いは、オフィスから行ったことです。

TCP プロトコルにはフロー制御が組み込まれていることを知っているので、1 回の Send 呼び出しで送信されるデータの量は問題にならないはずです。プロトコルは、サーバーの内部制限に合わせてそれ自体を調整するためです (私の記憶が正しければ. ..)

したがって、私が考えることができる唯一のことは、クライアントとルーターの間の中間ホストがクライアントを人為的にレート制限し、クライアントを切断していることです (512 バイトのチャンクでループ内のファイル データを送信します)。

これは、データを送信するために使用されるループです (buffer は、ファイル データを含むバイト配列です)。

お客様の ISP (またはお客様のファイアウォール) が、クライアント コードが一定時間内に送信できるデータ量に人為的なレート制限を課している可能性はありますか? もしそうなら、この状況を処理する最善の方法は何ですか? 明らかな解決策は、ソケット レベルでこれを行う方法がない限り、送信ループに遅延を導入することだと思います。

ISP がクライアント接続を強制終了することでレート制限違反を処理するというのは、私には非常に奇妙に思えます。TCP/IP の内部フロー制御/スロットリング メカニズムに依存しないのはなぜですか?

Socket#close()リモート側のソケットで呼び出されたかどうかをどのように検出しますか?

これは、私の組織のソフトウェア エンジニアの 1 人が提起した質問でした。私は最も広い定義に興味があります。

最近の質問のフォローアップとして、Javaでは、TCPソケットで読み取り/書き込みを試行せずに、ソケットがピアによって正常に閉じられたことを検出できないのはなぜでしょうか。Socketこれは、pre-NIOとNIOのどちらを使用するかに関係なく当てはまるようSocketChannelです。

ピアがTCP接続を正常に閉じると、接続の両側のTCPスタックがその事実を認識します。サーバー側（シャットダウンを開始する側）は状態FIN_WAIT2になり、クライアント側（シャットダウンに明示的に応答しない側）は状態になりCLOSE_WAITます。基盤となるTCP接続が終了したかどうかを確認するためにTCPスタックにクエリを実行できるSocketメソッドがないのはなぜですか？SocketChannelTCPスタックがそのようなステータス情報を提供しないということですか？それとも、カーネルへのコストのかかる呼び出しを回避するための設計上の決定ですか？

この質問に対する回答をすでに投稿しているユーザーの助けを借りて、問題がどこから来ているのかがわかると思います。接続を明示的に閉じない側は、最終的にTCP状態になりますCLOSE_WAIT。つまり、接続はシャットダウンの過程にあり、側が独自のCLOSE操作を発行するのを待ちます。isConnected戻っtrueたりisClosed戻ったりするのは十分公平だと思いますfalseが、なぜそのようなものがないのisClosingですか？

以下は、NIO以前のソケットを使用するテストクラスです。ただし、NIOを使用しても同じ結果が得られます。

テストクライアントがテストサーバーに接続すると、サーバーが接続のシャットダウンを開始した後でも、出力は変更されません。

Selenium-rc プロキシ サーバーでいくつかのコードをデバッグしています。原因はHttpURLConnection、HTTP ヘッダーを取得するためのインターフェイスが、次のようなヘッダー名の重複に対応していないオブジェクトにあるようです。

HttpURLConnection（とを使用getHeaderField(int n)して）ヘッダーを取得する方法によりgetHeaderFieldKey(int n)、2番目のCookieが失われるようです。私の質問は

1. HttpURLConnectionそれ自体が対処できないというのは本当ですか？
2. もしそうなら、それに対する回避策はありますか？

Vxworks は、標準の IP v4 および IP v6 ソケットをサポートしていますが、ソケットは他の目的にも使用されます。
他にどのようなタイプのソケットを利用できますか?

WindowsでSunJavaVM 1.5または1.6を使用して、ノンブロッキングソケットを接続します。次に、ByteBuffer出力するメッセージをaに入力write()し、SocketChannelに送信しようとします。

書き込まれる量がソケットのTCP出力バッファーのスペースの量よりも大きい場合、書き込みは部分的にしか完了しないと思います（これは直感的に期待できることであり、ドキュメントについての私の理解でもあります）が、そうではありません起こります。数メガバイトであっても、write() 常に書き込まれた全量を報告するように見えます（ソケットのSO_SNDBUFは8KBで、私の数メガバイトの出力メッセージよりはるかに少ないです）。

ここでの問題は、出力が部分的に書き込まれる場合（WRITEセレクターにインタレストセットを登録しselect()、残りが書き込まれるまで待機する）を処理するコードをテストできないことです。起こる。何がわからないの？

すべてのツール (nslookup、curl、wget、firefox など) がアドレスを解決できる完全に機能する Linux セットアップ (Ubuntu 8.04) を (私が知る限り) 持っています。ただし、次のコードは失敗します。

以下のことを確認しました。

• Perl は gethostbyname でアドレスを解決できます (つまり、以下のコードが機能します):

  my $ret = gethostbyname('stackoverflow.com'); print inet_ntoa($ret);

• 元のソース コードは Windows で動作します

• これは、LWP がこの動作を使用しようとするため (つまり、ホスト名を解決する必要がある)、動作するはずの方法です (実際、LWP が機能しない理由をデバッグしようとして、問題に遭遇しました)。
• スクリプトを実行しても DNS 要求は発行されません (そのため、名前の解決も試みません)。Wireshark で検証済み

listen(fd, backlog) を呼び出した後、ソケットでリッスンを解除することは可能ですか?

編集：自分自身を明確にしないという私の間違い。ソケットで一時的にリッスンを解除できるようにしたいと思います。close() を呼び出すと、ソケットが M2LS 状態のままになり、再度開くことができなくなります (さらに悪いことに、悪意のあるプログラムがそのソケットにバインドされる可能性があります)。

一時的にリッスンしないことは、アップストリームのロード バランサーに、このアプリがこれ以上リクエストを受け入れられないことを通知する方法です (最善の方法ではないかもしれません)。

非同期通信のCOMETの概念を研究するために、ソケットモジュールを使用して小さなPython + Ajaxプログラム（最後にリストされています）を作成しました。

アイデアは、ブラウザが私のpythonプログラムを介して互いにリアルタイムでメッセージを送信できるようにすることです。

秘訣は、「GETmessages / ...」接続を開いて、メッセージが応答するのを待つことです。

私の問題は主にsocket.recvを介して持っているものの信頼性にあります...

FirefoxからPOSTすると、うまく機能しています。

ChromeまたはIEからPOSTすると、Pythonで取得する「データ」が空になります。

ブラウザ間のこの問題について誰か知っていますか？

一部のブラウザは、「recv」の受信を強制終了するEOFまたはその他の文字を挿入していますか？

この問題に知られている解決策はありますか？

Pythonのserver.py：

HTML + Javascriptのclient.html：