0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【ポートフォリオ 06】UNIXドメインソケットを使ってRPCをPythonで実装してみた

Posted at

はじめに

クライアント・サーバモデルをベースとした自作のRPCプログラムを、クライアントサイドを Node.js、サーバサイドを Python で、UNIXドメインソケットを使って実装しました。

この記事では、課題に対してどのように取り組んだかについてまとめていきます。

GitHubはこちら

課題内容

異なるプログラミング言語で書かれたクライアントとサーバが共通の方法で通信し、特定の関数を実行できるようにするシステムを作ること
具体的には、クライアントが Python で書かれたサーバに対して、JavaScript(Node.js を使用)から命令を出す場面を想定しています。
https://recursionist.io/dashboard/course/31/lesson/1101 より引用

リクエストとレスポンスの形式

リクエスト
{
   "method": "subtract", 
   "params": [42, 23], 
   "param_types": ["int", "int"],
   "id": 1
}
レスポンス
{
   "results": "19",
   "result_type": "int",
   "id": 1
}

想定される課題の目的

以下の項目を理解して実装することと判断しました。

  • 異なる言語間でのデータのやりとりをどうするか
  • ソケット通信を通じてデータの送受信
  • 呼び出す関数をどう識別して実装するか

Remote Procedure Call(RPC)とは

ネットワークで接続された異なるコンピュータ上にあるプログラムの関数や手続きを、まるで自分のコンピュータのローカルにあるかのように呼び出して実行するための技術、またはそのプロトコルです。

RPCの処理の流れ

  1. 呼び出し側(クライアント) は、通常の関数を呼び出すのと同じコードを書く
  2. RPC が、その呼び出しをメッセージ(リクエスト)に変換し、ネットワーク経由でサーバーに送信
  3. 実行側(サーバー) はメッセージを受け取り、対応する関数を実行し、結果をメッセージ(レスポンス)としてクライアントに送信

実装方針(仮説)

以下の流れをクラスを設計して実装する

クライアント側(Node.js)

  1. CLI に「メソッド」「引数」「引数のデータ型」を入力
  2. クライアント番号を作成(自動生成するようにする)
  3. 引数チェック
  4. 関数名に関する文字列チェック
  5. 関数に応じた引数の数チェック
  6. CLI入力の変数への格納
  7. リクエストとしてオブジェクト化
  8. JSON形式に変換
  9. ソケット通信でJSONデータをサーバに送る
  10. エラーハンドリング

サーバ側(Python)

  1. ソケット作成・bind()・listen()・accept()
  2. 受け取ったJSON形式のリクエストデータをオブジェクト化(辞書化)
  3. 後で使用するものだけ変数に格納
  4. 辞書から関数欄を注目する
  5. 該当する関数一覧から、呼び出す関数を決める
  6. 引数のデータ型をチェックする
  7. Python用のデータ型に変換する
  8. 呼び出す関数に引数を渡す
  9. メソッドを処理する
  10. 結果を変数に格納する
  11. 辞書を作る
  12. JSON形式に変換する
  13. ソケット通信でNode.js(クライアント)側にJSONデータを渡す
  14. エラーハンドリング

検証

仮説で作った実装方針に基づいて実装しましたが、クラスの設計がままならず、長期間にわたる膠着状態が続いたため、関数ベースの処理に変更しました。

その結果、正常系までは実装することができました。

工夫した点

  • クライアント側での引数の型チェックを導入
    これによって、ネットワークに余計なデータを送らずに済みました。

  • Node.jsで readline を使用し対話型CLIを実現
    これによって、CLIへの入力が簡単になりました。
    当初、コマンド python ファイル名 関数名 引数 で実行できるようにしていたが、関数の存在や引数の型検証などを一度に行なう必要が出てきたため、入力の都度検証するように変更しました。
    これにより、エラーが発生した場合にどの入力に対するメッセージなのかをはっきりさせることができました。

仮説からの変更点

  • クラス設計の辞退
    予想を遥かに超える工数がかかってしまい、時間を要したため、今回はクラスを使った設計を行ないませんでした。

  • コマンドにまとめて記述から対話式の入力へ変更

今後の課題

  1. クラスを使って設計すること
  2. Node.js と Python で同じ method_table テーブルを参照する方法
  3. 複数のクライアントから同時接続できるようにすること
  4. 関数ごとに適切な引数のデータ型を表示すること
  5. 関数の追加がしやすい設計にすること
  6. メッセージの個別化
    関数ごとに引数に関するエラーメッセージの出力内容を変えること
  7. sort 関数の引数に上限を設けること
    現状ではいくらでも追加できるようになっているため
  8. エラーハンドリングを実装すること
    エラーが発生した場合にサーバが送信するレスポンスにエラーメッセージの詳細がないこと

気づき

  • 例外処理を実装中に、接続用ソケット作成後に while ループは不要であるとわかった

  • 処理の流れを紙に書き、正常系→異常系→テスト の順で実装していったが、最後まで時間内にやり切ることができなかったため、次回こそは時間内に一通り実装できるように、どんなタスクをいつまでに完了するか、タスク管理を細分化して徹底する必要があるとわかった

  • 使用したことないライブラリはじめ、書いたら小さくテストしてどのような挙動になるのかを確認しながら進めたことで手応えを感じながら実装することができた

  • どのカレントディレクトリからファイルを実行してもいいようにしたいという課題に対して、pathlib があると知り、「課題→解決策」の流れをベースに、その瞬間には必要ないものにはアクセスしないようにすることも必要だとわかった

まとめ

今回の課題では、UNIXドメインソケットをつかって、異なる言語間での情報のやり取りのために、JSON形式のデータの扱い方と処理の流れを、RPCプログラムの作成を通じて学ぶことができました。

当初の予定では、クラスを使って実装しようとしましたが、想定以上に苦戦してしまい、時間を浪費していたため、方針を切り替えて、関数ベースで作成することにしました。

この関数ベースのコードを、どのようなクラスに分けるのが最適かは、今後の課題とし、プログラムが1周したタイミングで再び取り組んで改善していきたいと思います。

最後までお読みいただき、ありがとうございました。

参考URL

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?