私が勤務しているオフィスの内部電話システム ソフトウェアに取り組んでいます。私たちは Twilio を使って電話ツリーを管理していますが、着信を監視し、発信者が私たちの担当者の 1 人に接続されたら転送するためのより良い方法を作成したいと考えています。
私たちは混合 (Windows と Mac) 環境にいるので、このアプリケーションのデスクトップ部分を作成するために Python で実行することにしました。私は (ほとんどの場合) このプロジェクトのペンと紙の段階にいます。Python/TKinter の経験と TCP ソケットの経験 (Python ではなく CakePHP を使用) があり、サーバー (Twilio にコマンドを発行している) とクライアント アプリの間のパケット転送を管理する方法についていくつか質問があります。
クライアント アプリケーションは、通話キュー内の発信者の数をユーザーに表示し、ユーザーが自分の電話で通話を受けられるようにし、発信者をキュー (または別のエージェント) に送り返します。これを行うことを検討した2つの方法を次に示します。
方法 1
クライアント (Python) アプリケーションは、VPS からの TCP 接続をリッスンします。これはメモリ消費量が最も少ない方法ですが、特にバフサイズに関するこの投稿を読んだことで、
に関して：「着信パケットの長さが正確にわかっているプロトコルを使用している場合、処理しているパケットに必要なものを「せいぜい」だけ読み取ることが明らかに好ましいです。そうしないと、次のパケットに食い込む可能性がありますそれはイライラするでしょう。」
これは、アプリケーション開発者にとっては望ましいことですが、基盤となるネットワーク スタックにとってはおそらく非効率的です。第 1 に、追加のネットワーク I/O に使用できるソケット バッファ スペースが占有されます。第 2 に、recv() を作成するたびに、システム コール/カーネル スペースに飛び込むことになり、移行のパフォーマンスが低下します。できるだけ少ないシステムコールでカーネルスペースからユーザースペースにできるだけ多くのデータを取得し、そこでメッセージの解析を行うことが常に望ましいです。これにより、アプリケーション コードとメッセージ処理がさらに複雑になりますが、おそらく最も効率的です。
私は本当に葛藤しています - 次のパケットを食べることは問題ですか? バフのサイズを予測するにはどうすればよいですか、または予測する必要がありますか?
方法 2
毎秒「ユニオンの状態」をアプリケーションにクエリさせることができましたn。しかし、それは無駄に思えます。
正解は？足りないものはありますか？