問題タブ [berkeley-sockets]

スキーマの実装段階で、コードが使用している以下のパラメーターを見つけました。以下に示すように、デフォルト値を使用しています。

私の質問: 上記の 7 つのパラメーターの重要性を理解していただけますか? 必要に応じて、これらの値をいつ調整するかを知ることができますか?

バークレー ソケットを使用して C++ で記述した Web HTTP/1.1 サーバーの実装があります。リクエストとレスポンスの多重化を可能にする HTTP/2.0 (または SPDY) のサポートの実装を検討しています。

HTTP/2.0 のバイナリ フレーミング レイヤーは、クライアントとサーバーが HTTP メッセージを独立したフレームに分解し、それらをインターリーブし、反対側で再構築できるようにすることで、完全な要求と応答の多重化を可能にします。

私の質問は次のとおりです。バークレー ソケット API を使用して記述している既存の HTTP/1.1 プログラムで、HTTP/2.0 (または SPDY) タイプの要求と応答の多重化を有効にするにはどうすればよいですか? おそらく、HTTP/2.0 (または SPDY) でサポートされている前述のフレーム多重化は、TCP/IP スタックの既存のメカニズムによって既に処理されているのでしょうか?

説明:

単一の接続を使用して複数の要求と応答を並行して配信する多重化の部分に特に興味があります。仕様から、これがアプリケーションレベルのプロトコルでどのように実装されているかわかりませんか? 何か案は？

コードをたどってパッシブソケットを理解しようとしています

http://merkez.ube.ege.edu.tr/~erciyes/ube528/passivesock.c

そして、次のコードが見つかりました

についていくつか質問がありますhtons(ntohs((u_short)pse->s_port) + portbase);

ポートベースとは何ですか? コメントを見つけましたが、u_short portbase = 0; /* port base, for non-root servers */その意味はわかりますか?

「パッシブ ソケット ポートベース」でググってみましたが、役立つ情報が見つかりません。

事前にt​​hx。

私は C++ クラスの基本的なネットワーク プログラミング セットを作成しました (tcp_socket、udp_socket、および ip_address ラップ クラス クラスにすぎません)。I/O 多重化サーバーで問題が発生しています。説明させてください：

シナリオは次のような方法です。

このスキームの上に、アプリケーションのコンテキストに応じて、下層レベルの抽象化を追加しました: 次のようなものです。

メインプログラムコードはこのようなものです

これは最初のクライアントでは機能しますが、2 番目のクライアントが来ると HELO 応答を受け取りますが、2 番目のクライアントでは V.push_back(*newClient) で最初の接続が閉じられます()。何がうまくいかないのですか？

sadhdagrecvへの最初の呼び出しでのサーバー recv 。

recv サーバーへの 2 回目の呼び出しで recv

サーバ側：

関数 s2 はスレッドによって実行され、引数がソケット情報とともに渡されます。そこで接続が受け入れられ、新しく受け入れられたクライアントで send と recv が呼び出されます。

なぜこれが起こっているのですか？またはこれを回避する方法は？

私のシステムは、Ubuntu を実行している ARM 上の C++ です。

ブロッキング読み取りを実行しようとすると、バークレー ソケットで問題が発生し、エラーが発生し、コードが EAGAIN になります。コードにタイマーを入れたところ、ソケットのタイムアウト前にエラーが発生していることがわかりました。私も接続しているデバイスを見て、ソケットが閉じませんでした。

これがどのように関連するのかはわかりませんが、これは gdb でプログラムを実行しているときにのみ発生するようです...少なくとも、私が気付いたのはそのときだけです。

これは、コードの簡略化されたバージョンです。小さくするためにエラーチェックを外しました。

iOS で、SO_RCVTIMEO を使用してタイムアウトが設定されたブロッキング ソケットを取得した場合。デバイスが接続されている WiFi ネットワークを変更すると、recv の呼び出しは適切にタイムアウトしますが、errno は EWOULDBLOCK として報告され、recv は -1 を返します。

これにより、デバイスが別のネットワークエンドポイントに接続されているため、この時点で現実的には不可能な場合に、外部処理ループがソケットに再度アクセスしようとします (現在利用可能なデータがないように見えるため)。

ネットワークを完全に強制終了すると、recv の呼び出しが何度も繰り返され、EWOULDBLOCK が何度も発生した後、最終的に ETIMEDOUT で失敗します。

なぜこれが起こるのですか？ソケット接続が壊れて、ENETRESET または同様の errno で失敗するべきではありませんか?

SO_RCVTIMEO がない場合、WiFi ネットワークが変更されると、ソケットは永久にブロックされます。ブエノもありません。

編集: ローカル ソケットで SO_KEEPALIVE を有効にして、基になるネットワーク エンドポイントが変更されたためにリモート ソケットが応答を停止したことを検出できると思います。これもうまくいかないようです。