あの年私たちが追いかけたネットワークライブラリ(PartI)
4856 ワード
転載先:https://microcai.org/2015/09/14/history-of-network-libraries-part-one.html#disqus_thread
#なぜC++でサービス・エンド・プログラムを作成するのですか?答えが性能なら、平気な人もいるに違いない.性能が足りないと思ったら、機械をつければいいです.しかし、より少ない機械は、より低いエネルギー消費、より少ないハードウェア投入、より少ない人的資源投入を意味し、機械を維持する.要するに、より低いコストです.
C++の開発速度が遅すぎると言う人もいるに違いない.しかし、これは絶対的なものではありません.C++も非常に迅速な開発が可能です.「シナリオは一時的に爽やかで、火葬場を再構築する」*ということわざがあるが、シナリオ言語開発のプロジェクトがメンテナンス段階に入った後、無限の災難を語っている.C++は数十年の発展を経て、巨大なツールチェーンを持っている.動的分析でも静的分析でも多くのツールがあり、プログラマーのエラーを減らすのに役立ちます.c++は優れた設計、厳格な検査のおかげで、大型の工事ほど開発コストを下げることができます.
しかし、これはC++が小型プロジェクトに適していないという意味ではありません.小型のプロジェクトでも、迅速に開発できます.C++11が始まると、もう新しい言語のように感じられるので、完全にスクリプトの形で使用することができ、スクリプト言語を超えた開発速度を得ることができ、コンパイルの最適化のおかげで、俗っぽくないランタイム性能を得ることができます.C++は魚と熊掌を兼ね備えた言葉です.
なぜasioというライブラリを使うのですか?
実際にC++を使用してサービス・エンド・プログラムを開発すると、数え切れないほど選択肢があります.ACEとか、libuvとか、libeventとか、libevとか、epoll/iocpのようなシステムAPIを直接使うこともできます.なぜasioを使うのですか?
##年間使用したネットワークライブラリ
コンピュータ史前の文明時代には、「c 10 k problem」という世界的な難題があった.これはy 2 k problemに続いてもう一つの重大な難関攻略プロジェクトです.世界中の文芸青年がこの問題を解決しようとする栄誉は、まさに八仙が海を渡って、それぞれ神通を示していると言える.
その年、NPTLはまだ研究されていなかった.何千ものスレッドが作成できない年、windowsはまだ青い画面の中であがき、ネットワークを顧みる暇がない.
しかし、曙光はまだある.非同期の出現は人に希望を与えた.古いUNIXはとっくに考えていたが、select()システム呼び出しを提供して駆使した.しかし問題は、selectは1024個のファイル記述子しかサポートできず、windows上のselectは64個しか使用できないほど劣る.定義を修正することによって1万個のファイル記述子を強制的に受け入れても、実際の問題は解決しない.selectは本当に遅いです.
このような背景の下で、IBMのお兄さんはMSの弟を率いて先にIOCPをした.しかし、オープンソースの人にはオープンソースのやり方があり、NIH症候群の影響でBSDの人は天下に歯を食いしばってKqueueを発明した.同様にNIH症候群の影響で、LinuxのM*のサルの群れがepollを作り出した.
分裂して頭が痛い.
しかし、彼らは自分の新しいインタフェースがselectに質的な向上があり、c 10 k問題を解決する不二法宝だと主張している.君が使っても使わなければならない,使わなくても使わなければならない.自分で作成したネットワークプログラムがプラットフォームにまたがるように、プログラマーは3つのそれぞれを陣とする法宝の膜拝学習を始めた.複数の互換性のないAPIに対応する必要があるほか、非同期自体もより高度な抽象が必要であり、プログラマーを非同期コードを書く地獄モードから救う必要がある.そこでプログラマーたちは天に昇って地に入ることができない法宝の法宝を必要とし、この3つの法宝を統御しなければならない.
先頭に立ったのはACEだ.
同前のACE
ちょうど乱世が過ぎたばかりで、天下は未定で、C++委員会の老人たちは韬光養晦で、世事を聞かない.いわゆる乱世は英雄を出して、英雄は少年を出して、オーウェン大学は有名な秀才を出しました.その洋々たる雄文「Pattern-Oriented Software Architecture」で首府学城を挙げ、ACEのために揺るぎない地位を築いた.
ACEの名前は、Adaptive Clubbed Rodからインスピレーションを受けたのかもしれない.これも当時の英雄少年の宝物だった.宝物である以上、思い通りにならなければならない.つまり、後の葫芦ワは「如意の宝物」を恐れた.
ACE如意はどこにありますか?一つは、IOCP/kqueu/epoll/select/you_をサポートname_it各種インタフェース、号曰に跨ることができないプラットフォームはありません.2つ目は、複数のモデルをサポートすることです.これらのモデルは『Pattern-Oriented Software Architecture』で詳しく述べられている.ACE自体がこの論文の実践であり、紙の上で得られたことを最後に浅く知っているからだ.インタフェースとモードの組み合わせの下で、何種類、コードを修正しないで適応することができます.
しかしACEは結局少し柔らかくて、数年もしないうちに勢いを失った.今は古いプログラマーのほかにも使っていますが、新生代のプログラマーはもうACEを使っていません.どうしてですか.陳碩氏はブログで、ACEは複雑すぎて、カプセル化しようとする対象よりも複雑だと話しています.プログラマーはあなたの如意な宝物で他の3つの宝物を制御することを期待しています.結局、あなたは彼らよりも難しいです.ACEは初期のC++ライブラリが犯す間違いを犯し、設計しすぎ、java化しすぎた.Java化とは,インタフェースの代わりにオブジェクトを,コールバックの代わりに虚関数を用いて組合せの代わりに継承することである.テンプレートの代わりにダミークラスを使用します.対象間の関係は複雑で、一発で全身を動かす.著者を除いてACEの開発に参加できる人はいない.
同時に、C言語の回帰は背後でひっそりと行われている.C言語の復活は、より悪い代替品、libeventとlibev、nodejsの盛んな東風に乗って来たlibuvをいくつかもたらした.
元のlibevent
C言語は頑強な生命力を持っていて、もちろん、これはC言語がどれだけ良いためではありませんて、後続の章で私達はまた深くC++の相対的なCの改善を検討します.C言語の粘り強さは人間の生まれつきの怠惰と偏見と一定の関係がある.このような惰性は遭遇に伴って安定し、自分の意見に固執していることを示している.C++を必死に否定し、Cを固守し、Cの欠点を無視し、C++のCに対する改善を中傷しなければならない.固守の結果は原始的なlibeventである.しかし、保守党の巨大な人数の優位性のため、libeventはその大衆の基礎が良好であるべきで、空前の広範な使用を獲得した.
libeventは名前の通り、非同期イベントフレームワークです.OSからイベントを入手し、配布します.配布メカニズムは「コールバック関数」です.非同期非同期は、結局、オペレーティングシステムから取得されたイベントを処理することです.iocpもepollも、イベントを取得するためのインタフェースにすぎません.libeventはACEの華やかで実在しない包装を取り除き、非同期イベントを保持し、モデルを極めて簡素化した.ソフトウェアエンジニアリングは悪い発明であり、簡単な問題を複雑化したことがないと言わざるを得ない.libeventは簡単な問題を簡単にして、非同期ネットワークのプログラミングを素朴にして、言うべきで、もともと良いライブラリです.
しかしlibeventは、グローバル変数の使用などの設計欠陥のため、タイマが時間ホッピングを処理できないなどの設計欠陥によりlibevの出現を招いた.libevはlibeventの欠陥を克服するために誕生した.しかし、libevはきっといいのだろうか.
閉じ込められたlibev
libevはlibeventへの恨みを持って生まれた.libeventのすべての欠点を吸収しましたが、改善を約束しました.しかしlibevはどのように改善しましたか?libevはすでに十分に原始的で、下へ改善するのはやはり人に直接システムのapiを使うようにして、上へ改善して、1つはlibeventとの重なりを招くことができて、2つはすぐにC言語の強要の束縛にぶつかりました.
C言語は文法が簡潔であることで有名である.しかし、必要な抽象能力が欠けており、C言語の非同期プログラムの作成は、アンディがハンマーを持って肖生克刑務所の壁を切り裂いたようになった.できますが、多大な労力と時間がかかります.非同期プログラムを作成するには、最も必要な2つの抽象能力があり、1つはコヒーレンスであり、2つは関数オブジェクトであり、匿名関数オブジェクト、すなわちlambdaを含む.Cは一切ありません.関数オブジェクトは閉パケットを実現することが不可欠であり,関数オブジェクトがなければ
Cには多くの欠点があるが、libevはIOCPをサポートしていないため、Cの欠点に引きずられなければならない.そこでlibuvはlibevにお尻を拭いてあげました.iocpをサポートしたlibuvは本当にCそのものの欠点しかないのでしょうか?
混乱したlibuv
libuvはC言語の非同期ライブラリが達成できる最高の高さと言える.完全にC言語の自身のボトルネックに触れ、libuvはnodejsの下位ライブラリにすぎず、上位ソフトウェアはjavascript言語に移行してCの束縛を避けた.
本当にそうなの?libuv自身にはどんな欠点がありますか?
オープンソースコミュニティavplayerの大拿jackarainは、ネットワークライブラリが良いかどうかは、TCP閉鎖を正しく処理しているかどうかを見て、read writeが実現したuiが間違っていると言ったことがある.libuv残念なことに、不合格です.libuvのuv_writeは値を返さず、空のコールバックを許可します.つまりwriteエラーを無視します.ネットワークエラーの場合、libuvのユーザーはぼんやりとエラーを知っているしかありません.エラーはどこですか.データはいったい送ったのか.いっさい知らない.データをuv_に渡すwrite後は、バカな勘定ですが、TCPの頼りない言い方はここから伝わったのでしょう.
#なぜC++でサービス・エンド・プログラムを作成するのですか?答えが性能なら、平気な人もいるに違いない.性能が足りないと思ったら、機械をつければいいです.しかし、より少ない機械は、より低いエネルギー消費、より少ないハードウェア投入、より少ない人的資源投入を意味し、機械を維持する.要するに、より低いコストです.
C++の開発速度が遅すぎると言う人もいるに違いない.しかし、これは絶対的なものではありません.C++も非常に迅速な開発が可能です.「シナリオは一時的に爽やかで、火葬場を再構築する」*ということわざがあるが、シナリオ言語開発のプロジェクトがメンテナンス段階に入った後、無限の災難を語っている.C++は数十年の発展を経て、巨大なツールチェーンを持っている.動的分析でも静的分析でも多くのツールがあり、プログラマーのエラーを減らすのに役立ちます.c++は優れた設計、厳格な検査のおかげで、大型の工事ほど開発コストを下げることができます.
しかし、これはC++が小型プロジェクトに適していないという意味ではありません.小型のプロジェクトでも、迅速に開発できます.C++11が始まると、もう新しい言語のように感じられるので、完全にスクリプトの形で使用することができ、スクリプト言語を超えた開発速度を得ることができ、コンパイルの最適化のおかげで、俗っぽくないランタイム性能を得ることができます.C++は魚と熊掌を兼ね備えた言葉です.
なぜasioというライブラリを使うのですか?
実際にC++を使用してサービス・エンド・プログラムを開発すると、数え切れないほど選択肢があります.ACEとか、libuvとか、libeventとか、libevとか、epoll/iocpのようなシステムAPIを直接使うこともできます.なぜasioを使うのですか?
##年間使用したネットワークライブラリ
コンピュータ史前の文明時代には、「c 10 k problem」という世界的な難題があった.これはy 2 k problemに続いてもう一つの重大な難関攻略プロジェクトです.世界中の文芸青年がこの問題を解決しようとする栄誉は、まさに八仙が海を渡って、それぞれ神通を示していると言える.
その年、NPTLはまだ研究されていなかった.何千ものスレッドが作成できない年、windowsはまだ青い画面の中であがき、ネットワークを顧みる暇がない.
しかし、曙光はまだある.非同期の出現は人に希望を与えた.古いUNIXはとっくに考えていたが、select()システム呼び出しを提供して駆使した.しかし問題は、selectは1024個のファイル記述子しかサポートできず、windows上のselectは64個しか使用できないほど劣る.定義を修正することによって1万個のファイル記述子を強制的に受け入れても、実際の問題は解決しない.selectは本当に遅いです.
このような背景の下で、IBMのお兄さんはMSの弟を率いて先にIOCPをした.しかし、オープンソースの人にはオープンソースのやり方があり、NIH症候群の影響でBSDの人は天下に歯を食いしばってKqueueを発明した.同様にNIH症候群の影響で、LinuxのM*のサルの群れがepollを作り出した.
分裂して頭が痛い.
しかし、彼らは自分の新しいインタフェースがselectに質的な向上があり、c 10 k問題を解決する不二法宝だと主張している.君が使っても使わなければならない,使わなくても使わなければならない.自分で作成したネットワークプログラムがプラットフォームにまたがるように、プログラマーは3つのそれぞれを陣とする法宝の膜拝学習を始めた.複数の互換性のないAPIに対応する必要があるほか、非同期自体もより高度な抽象が必要であり、プログラマーを非同期コードを書く地獄モードから救う必要がある.そこでプログラマーたちは天に昇って地に入ることができない法宝の法宝を必要とし、この3つの法宝を統御しなければならない.
先頭に立ったのはACEだ.
同前のACE
ちょうど乱世が過ぎたばかりで、天下は未定で、C++委員会の老人たちは韬光養晦で、世事を聞かない.いわゆる乱世は英雄を出して、英雄は少年を出して、オーウェン大学は有名な秀才を出しました.その洋々たる雄文「Pattern-Oriented Software Architecture」で首府学城を挙げ、ACEのために揺るぎない地位を築いた.
ACEの名前は、Adaptive Clubbed Rodからインスピレーションを受けたのかもしれない.これも当時の英雄少年の宝物だった.宝物である以上、思い通りにならなければならない.つまり、後の葫芦ワは「如意の宝物」を恐れた.
ACE如意はどこにありますか?一つは、IOCP/kqueu/epoll/select/you_をサポートname_it各種インタフェース、号曰に跨ることができないプラットフォームはありません.2つ目は、複数のモデルをサポートすることです.これらのモデルは『Pattern-Oriented Software Architecture』で詳しく述べられている.ACE自体がこの論文の実践であり、紙の上で得られたことを最後に浅く知っているからだ.インタフェースとモードの組み合わせの下で、何種類、コードを修正しないで適応することができます.
しかしACEは結局少し柔らかくて、数年もしないうちに勢いを失った.今は古いプログラマーのほかにも使っていますが、新生代のプログラマーはもうACEを使っていません.どうしてですか.陳碩氏はブログで、ACEは複雑すぎて、カプセル化しようとする対象よりも複雑だと話しています.プログラマーはあなたの如意な宝物で他の3つの宝物を制御することを期待しています.結局、あなたは彼らよりも難しいです.ACEは初期のC++ライブラリが犯す間違いを犯し、設計しすぎ、java化しすぎた.Java化とは,インタフェースの代わりにオブジェクトを,コールバックの代わりに虚関数を用いて組合せの代わりに継承することである.テンプレートの代わりにダミークラスを使用します.対象間の関係は複雑で、一発で全身を動かす.著者を除いてACEの開発に参加できる人はいない.
同時に、C言語の回帰は背後でひっそりと行われている.C言語の復活は、より悪い代替品、libeventとlibev、nodejsの盛んな東風に乗って来たlibuvをいくつかもたらした.
元のlibevent
C言語は頑強な生命力を持っていて、もちろん、これはC言語がどれだけ良いためではありませんて、後続の章で私達はまた深くC++の相対的なCの改善を検討します.C言語の粘り強さは人間の生まれつきの怠惰と偏見と一定の関係がある.このような惰性は遭遇に伴って安定し、自分の意見に固執していることを示している.C++を必死に否定し、Cを固守し、Cの欠点を無視し、C++のCに対する改善を中傷しなければならない.固守の結果は原始的なlibeventである.しかし、保守党の巨大な人数の優位性のため、libeventはその大衆の基礎が良好であるべきで、空前の広範な使用を獲得した.
libeventは名前の通り、非同期イベントフレームワークです.OSからイベントを入手し、配布します.配布メカニズムは「コールバック関数」です.非同期非同期は、結局、オペレーティングシステムから取得されたイベントを処理することです.iocpもepollも、イベントを取得するためのインタフェースにすぎません.libeventはACEの華やかで実在しない包装を取り除き、非同期イベントを保持し、モデルを極めて簡素化した.ソフトウェアエンジニアリングは悪い発明であり、簡単な問題を複雑化したことがないと言わざるを得ない.libeventは簡単な問題を簡単にして、非同期ネットワークのプログラミングを素朴にして、言うべきで、もともと良いライブラリです.
しかしlibeventは、グローバル変数の使用などの設計欠陥のため、タイマが時間ホッピングを処理できないなどの設計欠陥によりlibevの出現を招いた.libevはlibeventの欠陥を克服するために誕生した.しかし、libevはきっといいのだろうか.
閉じ込められたlibev
libevはlibeventへの恨みを持って生まれた.libeventのすべての欠点を吸収しましたが、改善を約束しました.しかしlibevはどのように改善しましたか?libevはすでに十分に原始的で、下へ改善するのはやはり人に直接システムのapiを使うようにして、上へ改善して、1つはlibeventとの重なりを招くことができて、2つはすぐにC言語の強要の束縛にぶつかりました.
C言語は文法が簡潔であることで有名である.しかし、必要な抽象能力が欠けており、C言語の非同期プログラムの作成は、アンディがハンマーを持って肖生克刑務所の壁を切り裂いたようになった.できますが、多大な労力と時間がかかります.非同期プログラムを作成するには、最も必要な2つの抽象能力があり、1つはコヒーレンスであり、2つは関数オブジェクトであり、匿名関数オブジェクト、すなわちlambdaを含む.Cは一切ありません.関数オブジェクトは閉パケットを実現することが不可欠であり,関数オブジェクトがなければ
void*ポインタを携帯する形式で完全に迂回するしかなく,煩雑で言うまでもなく,特にエラーが発生しやすい.プログラムにもタイプの強転があちこちに詰まっています.void*に渡すために一時的に定義されたタイプがあちこちにあります.Cには多くの欠点があるが、libevはIOCPをサポートしていないため、Cの欠点に引きずられなければならない.そこでlibuvはlibevにお尻を拭いてあげました.iocpをサポートしたlibuvは本当にCそのものの欠点しかないのでしょうか?
混乱したlibuv
libuvはC言語の非同期ライブラリが達成できる最高の高さと言える.完全にC言語の自身のボトルネックに触れ、libuvはnodejsの下位ライブラリにすぎず、上位ソフトウェアはjavascript言語に移行してCの束縛を避けた.
本当にそうなの?libuv自身にはどんな欠点がありますか?
オープンソースコミュニティavplayerの大拿jackarainは、ネットワークライブラリが良いかどうかは、TCP閉鎖を正しく処理しているかどうかを見て、read writeが実現したuiが間違っていると言ったことがある.libuv残念なことに、不合格です.libuvのuv_writeは値を返さず、空のコールバックを許可します.つまりwriteエラーを無視します.ネットワークエラーの場合、libuvのユーザーはぼんやりとエラーを知っているしかありません.エラーはどこですか.データはいったい送ったのか.いっさい知らない.データをuv_に渡すwrite後は、バカな勘定ですが、TCPの頼りない言い方はここから伝わったのでしょう.