IoT+WEBのためのホームサーバ計画の実装編17。ファイル名くらい決めとく。
ちょっと雑なもんでっ(^^;)
こーゆーとこに性格がでちゃうみたいで。
ファイル名とか、ほとんどテキトーに作ったりするもんだから、
あとあと、
えっと、、どのファイルだっけか。。。
とか考えるという無駄な時間使っちゃったりするわけで。
だから、ファイル名くらいは最初に決めときますよ。
あ、ここでいうファイル名は、そう、Module名というか、
最終的に実行すべきというか、エントリポイントを含むやつっていうか、
Python的に言えば、
if name == ‘main‘:
が、最終実行になるようなファイルです。
逆に言うと、個々のファイル名は機能を表すファイル名をつけるので、
そんなに迷うことは無いです。
今回の登場Module
今回は、だいたい以下の3つ+α。
■起動するもの■
WebServer側で動作させるさせるもの①
➡frAroundWeb.py
HomeServer側で動作させるさせるもの
➡frMhs.py
Iotコントローラ側で動作させるさせるもの
➡frMhc.py
αの部分はPythonではなく、
WebServer側で動作させるさせるもの②
➡Webサーバ。(Nginx/PHP7)
です。
まぁ何度も説明してる通り、概要を書くと、こういう風になります。
WebServer側で動作せるもの①
● WebSocketサーバ。
HomeServer(frMhs.py)からと、ユーザがWeb経由でアクセスしてくるものと、2系統のWebSocketを処理する部分。
●TCP/IPサーバ
WebServer側のPHPからアクセスされる部分。
要するに、PHPとPythonとのI/Fとして。
または、PHPと、なんらかのPython以外のModuleとのI/Fとして。
または、何かから何かへのI/Fとして。
この部分の私としての歴史は長く、2002年あたりの、Fedorシステム(JOBコントローラシステム)以来使い続けている感じです。
上記2つをまとめてPythonでマルチスレッドで実行します。
HomeServer側で動作させるもの
●UDPサーバ
IoTコントローラからのブロードキャストを受け取るI/Fとして処理する部分。
●TCP/IPサーバ
IoTコントローラ とのI/F部分。(最初のみUDP)
● WebSocketクライアント
WebServer側のWebSocketとやりとり、即ち、PUSH通信を受け取る側の部分。
● シリアル通信クライアント
画面表示としてシリアル通信をしてM5STACKとかに表示させる部分
●I2C部分
今回は非実装。画面表示として、2行テキストLCDとかを使う時用の部分。
上記をまとめて、Pythonのマルチスレッドで実行します。
なお、TCP/IPクライアント部分は、その都度都度に生成して実行させるので、独立したスレッドとしては実行しません。
また、IoTコントローラで実装しているタイムアウト検知もそのうちなんらかの理由で組み込むかもしれませんです。
IoTコントローラ側で動作させるもの
●UDPクライアント
HomeServerに自分を通知するための部分。IPが変化するなどあるので、定期的に実行します。
●TCP/IPサーバ
HomeServerとのやりとりで使用。HomeServerとIoTコントローラは、同期も非同期もあるため、
両者とも、TCP/IPサーバ/クライアントの両方を持ちます。
ここまでWebSocketにしたらひとつで済むけど、そりゃやりすぎだな^^;
●タイムアウト検知
IoTコントローラの実行プロセスが戻ってこなかった時用。
どうにもスレッドでやるとコントロールが困難なため、プロセスで実行し、そのプロセスのタイムアウトを監視するもの。
以上をまとめて、Pythonの」マルチスレッドで実行します。
WebServer側で動作せるもの②
ここはごく普通に、Webサーバです。
●Nginx(+PHP)
ユーザからのアクセスする通常のWebサーバ機能と、
WebSocketを受け取るためのリバースプロキシサーバの2つの機能のためにNginxを採用します。
なお、WebSocketでは、そのままPythonのプロセスとやりとり可能ですが、
通常のWEB(のajax)とかではそのままPythonとのやりとりはできないので、
PHPからTCP/IP通信することによって、PythonとのI/Fをとります。
まぁもちろんWebサーバ側ではファイル名とか特に無いです。
しいていえば、index.phpですかねー。
もちろん、WebServer側は全てhttpsとwssです。
そのためにLet’s Encryptしますよ(o^^o)