サーバー・クライアント間の通信手法の改善案

[vain0x]

通信用のポーリングのコストが非効率なため、他によい方法がないか検討します

関連Issues: #70, #81

[vain0x]

(前提知識について 詳細すぎるけど参考になる資料. 適当な参考資料があれば教えてもらえると助かります)

現行の方法

• いま (v2.2.0)、サーバーとクライアント間の通信はクライアントの標準入出力を使っています
• タイマー で一定時間ごとに パイプ から読み取り可能なデータがあるかを確認しています (ポーリング)
  • 以下の2点で非効率です
  • データが来てなくても一定時間ごとに処理が発生する
  • データが来てから次にタイマーのメッセージが送られるまで読み取りが行われない
• また、開発環境限定で、クライアントプロキシー (kc_main_proxy.hsp) がサーバーとクライアントの間に挟まっています
  • これもポーリングによって標準入出力を読み書きしています

メッセージループ

• メインスレッドを起こすにはウィンドウメッセージを送る必要があります
  • HSPのランタイムは wait や stop で停止している間、メッセージループ を実行しています
  • すなわち、メインスレッドに送られてくるメッセージを待つためにスレッドをブロックしています
• また、スレッドメッセージを送る 方法は使えないはずです
  • スレッドメッセージはウィンドウにディスパッチされないので、おそらくメッセージループ内で処理する必要があります
  • メッセージループはHSPのランタイム内にあるのでknowbugからはアクセスできません
  • そのためメインスレッドに送ったメッセージをknowbug側で検出することはできないはずです

案1: 書き込み側が相手にウィンドウメッセージを送る

(採用予定)

• 何らかの方法で相手のウィンドウハンドルを取得します
  • サーバー側のウィンドウハンドルは、クライアントプロセスの生成時にコマンドライン引数か環境変数で指定して渡します
    • ウィンドウハンドルはプロセス間で同じハンドルによって参照できます
  • クライアント側のウィンドウハンドルは、初期化時のメッセージで渡します
• サーバー・クライアントのどちらも、メッセージをパイプに書き込んだ後、相手のウィンドウにメッセージを送ります
• サーバー・クライアントのどちらも、メッセージを受け取った時に、パイプからメッセージを読み取るようにしておきます

案2: 読み込み側が自分にウィンドウメッセージを送る

(却下)

• パイプを オーバーラップド モードで生成し、非同期の読み書きを有効にします
  • すなわち、パイプの読み書きの際にスレッドがブロックされなくなります
  • 代わりに、読み書きの完了時にイベントが発生するようにできます
• RegisterWaitForSingleObject を使って、イベントの発生時にコールバック関数が呼ばれるようにします
  • このコールバック関数によって読み込み側が自身の持つウィンドウにメッセージを送るようにしておきます
  • そのメッセージを受け取ったときに、読み取ったデータを処理するようにしておきます
• なおオーバーラップドのパイプは書き込みも非同期的に行われるはずなので、書き込み側のコードも変更の必要があります
• この方法は通信相手のウィンドウハンドルを知る必要がないので「自然な」通信方法だといえます
  • すなわち、サーバーがウィンドウハンドルを所持していない場合でも、クライアントはサーバーと通信できます
  • しかしクライアントはサーバーに対して固有のアプリであり、汎用的である必要はありません
  • 案1より迂遠であること、HSP側でコールバック関数を用意するのがめんどうであることから、これは却下します

案3: IO用のスレッドを立てる

(却下)

• メインスレッドとは別にIO (パイプの読み書き) 専用のスレッドを立てておきます
  • 送信用と受信用の2つを立てます
• 送信時は送信用のスレッドにメッセージを送ります
  • 送信用スレッドはメッセージが送られてくるのを待ち、送られてきたメッセージをパイプに書く、ということを繰り返します
  • また、メッセージを送信する際に前のメッセージの書き込みが完了していない場合、メインスレッドは送信用スレッドを待つことにします
    (バックプレッシャーの問題。詳細は略。条件変数を使うとできるはず)
• 受信用スレッドはパイプからの読み取りを同期的に行い、データを読み取るたびにメインスレッドにウィンドウメッセージを送る、ということを繰り返します
  • メインスレッドはそのメッセージが来たら、読み取ったデータを処理します
  • こちらもメインスレッドの処理が進行していないうちに次の読み取りを開始してしまうと大量のウィンドウメッセージが積まれることになってしまうので、メインスレッドがメッセージの処理を完了するまで、その次の読み取りデータを送るのは待つことにします (詳細略)
• この方法はサーバー・クライアント間の通信だけでなく、メインスレッドと送受信用スレッドの間の通信が発生するので、かなりややこしいです
  • スレッド間でデータの共有 (送受信に使うバッファーの受け渡し) も必要となります
  • 私は最初の時点ではこの実装を検討していましたが、このように複雑なので、却下します

[vain0x]

ウィンドウメッセージ WM_COPYDATA を使ってデータを受け渡す方法に変更しました

• サーバーは隠しウィンドウ (hidden_window) を持っています。これのウィンドウハンドルを server_hwnd と呼ぶことにします
• サーバーがクライアントを起動する際に、コマンドライン引数として server_hwnd を渡すようになります (--server-hwnd=数値)
  • ウィンドウハンドルは別のプロセスでも同じ数値です
• クライアントは起動後に自身のメインウィンドウのハンドル (client_hwnd と呼ぶ) をサーバーに渡します
  • 起動後にサーバーに送る initialize_notification メッセージにそのためのプロパティが追加されました
• サーバーがクライアントにメッセージを送る場合、クライアントのウィンドウに WM_COPYDATA メッセージを送ります
  • WM_COPYDATA の lparam には COPYDATASTRUCT へのポインタを渡します (wparam は使われません)
  • COPYDATASTRUCT にはデータへのポインタ (仮に p とする) と、そのサイズが含まれています。
    このデータはクライアントにコピーされます (そのコピーされたデータへのポインタを q とします。p はサーバープロセスのメモリーを指していますが、q はクライアントプロセスのメモリーを指しています)
  • クライアントがこのウィンドウメッセージを受け取った場合、lparam は COPYDATASTRUCT へのポインタで、そこにデータへのポインタ q と、そのサイズが入っています
  • クライアントにコピーされたデータはウィンドウメッセージの処理後に削除されます。
    つまり、ポインタ q はメッセージの処理後に無効になります
    (このときクライアントは受け取ったデータを解析して配列にコピーをとるだけなので、ポインタの有効期限の問題はないはずです)
  • サーバーからクライアントにメッセージを送るためにクライアントのハンドルが必要になったため、クライアントにメッセージを送れないタイミングが発生するようになりました。クライアントの起動に失敗した場合や、起動するまでの間には送れません
    • デバッギ (実行されているHSPスクリプト) が assert や logmes 命令を実行したとき、以前の実装では stopped_event や output_event をすぐにクライアントに送っていました。この変更によってそれはできなくなったため、これらのイベントはいったんサーバー内に溜め込んでおき、クライアントにメッセージを送れるようになったら送るという挙動に変更されました
• クライアントからサーバーにメッセージを送る場合も同様に、サーバーのウィンドウに WM_COPYDATA を送ります
  • (サーバーが終了したら terminate_event によってクライアントも終了するため、メッセージを送れないタイミングはないとみなしていいはずです)

参考:

• メッセージによるプロセス間通信 - Advanced HSP
• WM_COPYDATA メッセージ | Microsoft Learn

[vain0x]

コミット: ed196ae