トランセンドライブラリ4：はじめに

C ++でネットワークを操作するのは、1、2、3です。

network n = OpenNetwork(); connection c = n.OpenConnection("habrahabr.ru", 80); html_request h("GET", "/"); c << h; c.WaitForMessage(); n.Response(); std::cout << c;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

こんにちは、カブラヴィテス様、今日は過去4年間の私の仕事についてお話ししたいと思います。 私の創造について、私の人生について。 それは、ネットワークを操作するための多機能ライブラリ、その歴史とその作成理由、解決すべきタスク、内部構造についてです。



すぐに予約をしたいのですが、私の作品は自転車かもしれませんが、作成時でも、新しいバージョンへの移行時でも、満足できるアナログは見つかりませんでした。

物語

開始する

すべては2008年の夏に始まりました。 winsockを使用して、最初のサーバーを作成しようとしました。 本当に明確なものは何もなかったので、先生は重要ではありませんでした 。

また、不便なAPIに非常に腹を立て、すぐにすべてをカプセル化することを望みました。 私はその時c ++を知りませんでした、そして最初のバージョンは関数の名前を変更するだけでした（今は失われています）。



ますますネイティブのwinsockスキームから離れ、コミュニケーションをより透明にしました。 （たとえば、connect関数を呼び出すと、ソケットがすぐに作成され、dns要求が行われ、接続が開かれました）。 徐々に便利になり、ゲームを作ろうと決心しました。

古代の伝説

TL2バージョンの前は、大幅な改善は行われていなかったため、300行のコードを禁止しています。

実際のタスクの出現により、1つの接続（チャット、テクスチャ、音楽）で複数のデータを転送するという問題が発生しました。 進歩自体が始まったのはこのことです。 6か月の間にこの問題を解決し、最適なパケット分割、サービスメッセージの形式を選択し、テストを行いました。 その結果、ライブラリは最大255個の「メッセージ」の同時送信をサポートし、それぞれ最大4ギガバイトのサイズで、タスクにうまく対処しました。

残念ながら、スタッフリーク、利他主義のため、ゲームを書いたことはありません。 はい、そして競合他社が登場しました。 したがって、将来のバージョンの開発に休むことができました。

TL4

次の繰り返しは、C ++への移行と新しい標準の追加、新しいチップの使用、新しい機能でした。

ライブラリは、サーバーとクライアントの2つのモードで同時に完全に動作するようになり、プロキシまたはp2pタスクを解決できます。 最大メッセージサイズは無限に増加し、同時に送信されるメッセージの最大数は最大2 ^ 32です（255はアクティブに送信されます）。 自動再接続機能が追加され、メッセージの送信が優先されました。

ライブラリは非ブロッキングソケットで非同期になり、メインスレッドの負荷を軽減しました。 （たとえば、デフォルトでは、接続を開くにはTL2で443ミリ秒かかり、この数はTL4で17ミリ秒に短縮されました）。

暗号化、圧縮などが追加され、リストは長期間継続できます。

解決すべき主なタスク

ライブラリは、プラットフォームに関係なく、次のことを実行できます。

クライアントに-接続を開き、任意のソース（ファイル、配列、その他の接続）からデータセットを転送し、接続が何回中断されてもデータが配信されることを確認します。

サーバーはポートをリッスンする必要があり、接続数、各接続のトラフィック、オンライン時間、平均速度などに関する情報を常に直感的に把握できます。

例「PROXY」

 #include <tl4/def.h> using namespace ax::tl4; bool proxy( connection &c, message &m ) { std::string s; s << m; //   host:pass,   connection nc = c.GetNetwork().OpenConnection(s); nc << s; nc << c; nc >> c; return true; } void main() { network n = OpenNetwork(); port p = n.OpenPort(8080); p.NonTL4Compatible(true); p.OnOpenConnection(proxy); while (1) n.Response(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、例はエラー処理なしでシミュレートされ、実際に曲線（メッセージをstd ::文字列に変換しようとすると、プログラムは\ 0が到着するかタイムアウトによってブロックされます）が、本質は明らかです。

特徴

• プロトコル制限なし
• 暗号化、圧縮をサポート
• 最も正確な同期
• メッセージレベル、パッケージでのハンドラーの導入（暗号化）。 完全に変更可能なパケット構築パイプ。
• 接続を「仮想ネットワーク」に結合する（一度に処理されるグループ）。 ネットワーク間のすべての通信はスレッドセーフです。
• 1つの接続で最大40億のオブジェクトを同時に転送します。
• 構成可能な接続パラメーター、ソフトウェア速度制限など。
• 各接続またはグループのすべてのイベントのカスタムイベントハンドラー。
• オブジェクトの転送の優先順位、「今何を正確に転送するか」に対する完全な制御。
• 不完全なオブジェクト（トレント、インターネットラジオのストリームなど）を転送する機能。 サイズ制限はありません。
• 「新しいオブジェクト」、「オブジェクトの新しい断片」、「オブジェクトのダウンロードの完了」、「Nバイトごと」、「N秒ごと」の処理の可能性。
• 一箇所でのプロトコル開発。

一箇所のプロトコル

これは、コードを複製せずにクライアントサーバーアプリケーションを開発できる非常に便利な機能です。

小さな紹介。 各オブジェクトおよび各パッケージに対して、ハンドラーのキューが呼び出されます（明らかな理由でオンザフライで変更することはできません）。 ハンドラーには、エンコードとデコードの2つのメソッドがあります。 したがって、暗号化/復号化コード、圧縮/解凍コードは常に1つの場所にあります。 これにより、ハンドラーの正当性を確認できます-Testメソッドを呼び出すだけで、暗号化および復号化後に元のバージョンが取得されたランダムまたは提供されたデータを確認できます。

プロトコルにも同じことが言えます-プロトコル全体として、オブジェクトをメッセージに、メッセージをオブジェクトに変換できるのと同じメソッドがあります。

仕組み

ストリーム

プログラミングの世界のすべては、シーケンスを通して表現できます。 配列、文字列、ファイルはすべてバイトのシーケンスです。 変数とインバウンドアウトバウンド接続についても。

ストリームクラスシステムは、ストリームの物理ソースから抽象化し、情報で実際に発生する変換から抽象化するために作成されました。

stl :: streamに似ていますが、いくつか改善されています。

パイプ

単純なタスクを想像してください。ディスクから画像を転送したいのです。 これを行うには、ダウンロードしてbmp-> jpgに変換し、暗号化する必要があります。 これは、ハンドラーを次々に配置し、これが原子変換であると言うことで簡単に実行できます（給水を伴うアナロジー-パイプが突き合わせて行きます）。

 pipe *ImageTransferPipe( std::string filename ) { pipe_constructor c; c.add(new BMP2JPG()); c.add(new BlowFishCrypt()); pipe p(c); return p.GetScheme().Source(new read_file_stream(filename)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初はあまり明確で便利ではないようですが、APIを読んだ後は簡単になります。

すぐに使用可能な暗号化

ご想像のとおり、接続を作成する場合、論理的な機能は1つだけです。

 connection::SetHandler( pipe * )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

送信中の各バイトはこのハンドラーを通過し、受信中の各バイトは対応するプロセッサーも通過します（パイプ:: GetInverseScheme）。

複数のオブジェクトを一度に転送する

このアイデアは非常にシンプルで、必要な人とまだやっていない人に役立つと思います。

送信用のキュー内のすべてのオブジェクトは、255バイトずつ細断され、これらのブロックによって送信されます。 ブロックにはオブジェクトIDが提供されます。 オブジェクトは周期的に送信されます-最初、2番目、3番目、1番目、2番目、3番目。

ブロックは常に255バイトであり、サイズは提供されないことに注意してください。 突然ブロックが小さくなった場合、これはサービスメッセージによって調整されます。

オブジェクトの次の部分が突然「準備ができていない」（データなし）場合、準備ができた1つと引き換えに、非アクティブなキューに移動します。 これはすべて、システムメッセージによって規制されています。

システムメッセージ

それらにはいくつかの機能があります。 送信側は、アクティブ/非アクティブの回転を報告し、オブジェクトの終わりが近づいていることを警告し、オブジェクトの追加、「低レベル」例外の送信、オブジェクトのパイプ形式の送信を報告し、最も興味深いのは同期です。

マシン同期

正しく動作させるには、両端でオンにする必要があります。 このタスクのために、オブジェクトの優先度を認識する必要がありました。これらのサービスメッセージは、作成時にキューに追加する必要があります。

ホストはタイムスタンプをミリ秒で交換し、pingを受信します。 平均値を設定した後、彼らもそれを交換し始めます。 その結果、両方のマシンに応答時間があります。

最も興味深い部分は、サーバーソリューションから始まります。 pingが数百を超えるプレイヤーは私を理解するでしょう。 敵は数ミリ秒前に何か重要なことを知っているでしょう、そしてそれだけです。

次に、イベントがすべてのマシンに同時に到着するゲームを想像してください。これは単純に行われます。 同時メッセージを送信する場合、接続は遅延の順にソートされ、実際のデータは、接続の安定性を考慮して、推定到着時間が等しくなるように送信されます（有線ソリューションのエラーは10ミリ秒未満）。

なぜこの投稿なのか？

実際には、ライブラリは完全ではありません。 たとえば、予定されているすべての接続パラメーターがサポートされているわけではありません。暗号化アルゴリズムをそのまま使用したり、チェックサムを追加したりします。 一般的に、作業はまだ進行中です。

ここでは、宣伝するために表示されませんでしたが、アナログがあるかどうかを確認し（人々がそれを持っている方法を確認するためにいくつかのアイデアを盗みたい）、誰かがそれを必要とするなら（市場に行くのが理にかなっています）システム。

謝罪

プレゼンテーションの仕方、エラー、不正確さについておaび申し上げます。 カルマが低いため、「I am PR」というタグを追加できませんでした。 そして確かに無駄に、私はおそらくそれを行います。



UPD： 続き