[解決済み] Twistedの何がそんなにクールなのか？[クローズド］

質問

最近、Pythonの ツイスト フレームワークがロックで、他のフレームワークはそれに比べて見劣りするという話を聞くことが多くなっています。

誰かこれに光を当てて、おそらくTwistedと他のネットワーク・プログラミング・フレームワークを比較してもらえませんか。

どのように解決するのですか？

Twistedには、あなたがクールだと感じるかもしれない様々な側面があります。

Twistedはたくさんのプロトコル実装を含んでいます。つまり、リモートシステム（ほとんどの場合、クライアントかサーバーのどちらか）と話すために使えるAPIがあるはずです。 HTTP , FTP , smtp、pop3、imap4 , DNS , IRC、MSN、OSCAR、XMPP/Jabber , テルネット、SSH , SSL NNTP のいずれか、あるいは 本当に のような低レベルのプロトコル構築プロトコルの一つです。 DJB の ネットストリングス , 単純なラインオリエンテッドプロトコル のようなTwistedのカスタムプロトコルの一つもあります。 パースペクティブブローカー (PB) または 非同期メッセージングプロトコル(AMP) .

Twistedのもう一つのクールな点は、これらの低レベルなプロトコル実装の上に、しばしば、より使いやすい抽象化を見つけることができることです。 例えば、HTTPサーバを書くとき、Twisted Webは を提供します。 これは、リクエストがどのように応答されるかを定義するために、PythonオブジェクトからURL階層を構築することを可能にします。

これらのすべては、協調するAPIと結びついています。これは主に、この機能のどれもがネットワーク上のブロッキングによって実装されていないという事実によるもので、そのため スレッドを起動する必要がありません。 . これは、人々がしばしばTwistedの特徴として挙げるスケーラビリティに貢献します（ただし、それは単一のコンピュータのみを含むスケーラビリティであり、アプリケーションがホスト群の全体を使用するように成長するようなスケーラビリティではありません）。なぜならTwistedは単一のスレッドで何千もの接続を扱うことができ、それぞれが単一の接続に対して何千ものスレッドを持つよりもうまくいく傾向があります。

スレッド化を避けることは、テストとデバッグ（そしてそれ故に一般的に信頼性）にも有益です。 典型的なTwistedベースのプログラムでは、プリエンプティブなコンテキストスイッチはありませんので、一般的にロックについて心配する必要はありません。 異なるネットワークイベントの発生順序に依存するレースコンディションは、それらのネットワークイベントをシミュレートすることによって簡単にユニットテストできます（一方、コンテキストスイッチをシミュレートすることは、ほとんどの（どんな？）スレッディングライブラリによって提供される機能ではありません）。

Twistedはまた、本当に、本当に 品質へのこだわり . だから、あなたは 回帰を見つけることはほとんどありません というのは、私たちは、一般的な方法だけでなく、あなたがそれらを使うかもしれないすべての方法をテストしようとするためです。 これは、特に過去3、4年の間にTwistedに追加された（または修正された）すべてのコードに当てはまります。なぜなら、100％のラインカバレッジは、それ以来、最低限のテスト要件となっているからです。

Twistedのもう一つの見落とされがちな強さは、異なるプラットフォームの 風変わりな . 異なるプラットフォームには文書化されていないソケットエラーがたくさんあり、それらを扱うことはおろか、それらが存在することさえ学ぶのは本当に難しいことです。 Twistedはこれらのエラーを徐々にカバーするようになり、現時点ではかなり良くなっています。 若いプロジェクトにはこの経験がないので、おそらくあなたがリリースしたプロジェクトのユーザーにしか起こらないような、不明瞭な失敗モードを見逃してしまうのです。

とはいえ、私がTwistedについて最もクールだと思うのは、それがかなり退屈なライブラリであり、多くの本当に退屈な問題を無視して、ただ面白くて楽しいことに集中させてくれることです :)