問題タブ [network-protocols]

GPRS を介して通信する分散アプリケーションを使用しています。UDP パケットを使用してビジネス データを送信し、ICMP ping を使用して接続を確認します。そして今、プロバイダーから請求されるトラフィックの計算に問題があります。次の要因を考慮する必要があります。

1. UDP ペイロード: それは明らかです。
2. UDP オーバーヘッド: UDP ヘッダー + IP ヘッダー = 8 + 20 バイト。
3. データなしの ICMP エコー要求: IP ヘッダー + ICMP ペイロード = 28 バイト。
4. ICMP エコー応答: 3 のように。

上記は、データ パケットごとに、ペイロード + 28 バイトと ping ごとに 56 バイトが課金されることを意味します。私は正しいですか、それとも何かが欠けている/誤解していますか?

キャプチャされたTCPセッションで使用されるTCP輻輳制御アルゴリズムを決定するためのプログラムが欲しいのですが。

参照されているウィキペディアの記事には次のように記載されています。

TCP New Renoは最も一般的に実装されているアルゴリズムであり、SACKサポートは非​​常に一般的であり、Reno /NewRenoの拡張機能です。他のほとんどは、まだ評価が必要な競合する提案です。2.6.8以降、Linuxカーネルはデフォルトの実装をrenoからBICに切り替えました。2.6.19バージョンでは、デフォルトの実装が再びCUBICに変更されました。

また：

複合TCPは、公平性を損なうことなくLFNで良好なパフォーマンスを達成することを目的として、2つの異なる輻輳ウィンドウを同時に維持するTCPのMicrosoft実装です。これは、MicrosoftWindowsVistaおよびWindowsServer2008で広く展開されており、Linuxだけでなく古いMicrosoftWindowsバージョンにも移植されています。

どのCCアルゴリズムが使用されているかを判断するためのいくつかの戦略は何でしょうか（セッションをキャプチャするサードパーティから）？

アップデート

このプロジェクトは、これを行うためのツールを構築しました。

インターネットは最近、同種の輻輳制御から異種の輻輳制御へと進化しています。数年前、インターネットトラフィックは主に標準のTCP AIMDアルゴリズムによって制御されていましたが、インターネットトラフィックは現在、AIMD、BIC、CUBIC、CTCP、HSTCP、HTCP、HYBLA、ILLINOIS、LPなどのさまざまなTCP輻輳制御アルゴリズムによって制御されています。 STCP、VEGAS、VENO、WESTWOOD +、およびYEAH。ただし、異種輻輳制御を使用したインターネットのパフォーマンスと安定性の調査に関する作業はほとんどありません。基本的な理由の1つは、さまざまなTCPアルゴリズムの展開情報が不足していることです。このプロジェクトの目標は次のとおりです。

システムはUDPを使用し、前方誤り訂正を使用して、いくつかのパケットが失われた場合でも、再送信せずにメッセージ全体を送信できます。これは実際にうまく機能するのでしょうか、それとも余分なオーバーヘッドが無駄になりすぎるのでしょうか。

私は友人と別の口論をしています。

当事者間である種のイベント (メッセージ) を送信するために基本的に使用される単純な JSON ベースのプロトコルを設計する必要があると考えてください。

言って、何か

私はこのプロトコルを上記のように維持することを提案しますが、私の友人は次のようなことを提案しています:

彼の主張は、TCP と HTTP が「責任」の異なる層にあるように、このプロトコルはデータを分離しておくために「詳細」サブオブジェクトを使用する必要があるというものです。

彼が持っているもう 1 つの議論は、一致したイベントを処理するハンドラーは、"ルーティング" 情報 (event_id など) について何も認識してはならないというものです。

私の主張は次のとおりです。

1. この情報をハンドラーから隠すために、各メッセージ (およびネットワーク トラフィック。これは、大量のメッセージを交換するシステムにとって重要な場合があります) の長さを増やしています。

2. ハンドラーは、適切に応答するために、実際には「ルーティング」情報を知る必要があります。

   /li>

3. event_id などをハンドラーから隠す必要がある場合でも、ハンドラーに渡す前にそれらを取り除くだけで、トラフィックを節約できます。

このプロトコルは非常に単純で、他の人が使用することは想定されていません。

どう思いますか？

たまたま、actionscript 3とC＃の両方に実装されている無駄のない（xmlやjsonではない）パケットプロトコルはありますか？すでに両方の言語で実装されているものがあれば素晴らしいと思います。そうでない場合は、片側をコーディングする必要があるかもしれません。そうは言っても、C＃のシリアル化仕様を理解して（またはそのドキュメントを見つけて）それを使用するのは愚かで安全ではないので、AS3からC＃へのオブジェクトエンコーダーを作成する必要がありますか？

あまり普及していないアプリ（インスタントメッセンジャー）を使っています。使用するプロトコルを見つけようとしています。TCP/IP を使用していることはわかっていますが、サーバーに送信し、サーバーから受信しているすべてのコマンドを調べたいと考えています。

いくつかのスニファーを試しましたが、彼らはこのアプリケーションを名前で認識できず、さらに、関連のない 16 進コードがいくつか得られました。

アプリケーションの仕様を見つける方法はありますか?

（注：私はそれをグーグルで検索しましたが、何も見つかりませんでした。また、著者によるドキュメントもありません。）

SQL Server クライアント プロトコルの VIA プロトコルとは何ですか?

より正確には、VIA は何の略ですか?

チップメーカーのVIA向けですか？

ステートフル プロトコルを使用すると、Cookie のような「エミュレートされた状態」が一緒に失敗することが少なくなることがわかります。

ただし、実装が正しく、再接続されることを確認するためのテストがはるかに難しくなり、セッションの継続を処理するのが非常に難しくなる可能性があります。

常にステートレス プロトコルを使用する方が良いと考えられますか、それとも本当にドメイン固有ですか?

ステートフル プロトコルを使用すると認証が容易になると思いますが、他にステートフル プロトコルを使用する理由はありますか?

GUI を使用して実験的なネットワーク プロトコル (TCP/UDP) の開発を容易にし、簡素化するオープン ソースの高レベル ツールはありますか?

基本的には、「パケット」、「メッセージ」、「状態」、「バリデーター」、「ハンドラー」などを定義できる動的ステート マシン エディターのようなものです。

できれば、このようなツールは、プロトコルの関連するすべての側面 (つまり、クライアントとサーバー) を処理するのに十分なほど包括的であるため、高レベルのプロトコル記述を XML/RDF ファイルにシリアル化して、動的に作成するために使用できます。プロトコルを実装するためのアプリケーション コード (つまり、Python)。