とりあえず、TCP/IPもUDPでブロードキャストもWebSocketの一応Pythonで検証しました。
ここでWebSocketを考えるわけですが、
よく記事なんかだと、

『コネクションが確立したので自由にPUSH通信できる』

みたいな感じで書かれてたりするけど、
『自由に』っていったってどうするんでしょ？
そもそものトリガが外部からきたとすると、どうやればいいんでしょ？
的な。
というお話です。

そもそも、命令を受けるものと、WebSocketサーバが連携して動作してないとダメなわけで、、、
なんてことは当然わかるわけです。
要するに、そのI/F、何にするかってことになります。
命令を受けるものを、ここで仮に『トリガ』と呼ぶなら、
トリガにも、同期と非同期と考えられるわけで、
そう、同期、非同期、、、ここはこの部分はTCP/IPってことで考えてみましょう。
すると、どうでしょ。こんな感じかな。

これはWebサーバ経由で何かしら命令を投げるという想定で、
WebサーバがAPIでもRESTでもPOSTでもなんでもいいんですけど、
それを受けたタイミングでsocketのクライアントを生成し、
socketサーバに投げちゃおうっていう感じです。

そうすると、それを受ける方のプロセスは、WebSocketサーバとTCP/IPメッセージングサーバの２つが連携して動作してないとダメだって話ですね。
まぁここらへんはPythonでマルチスレッドでちょこちょこってやれば何とかなります。

まぁでも、PUSH通信っていっても、全てのクライアントに一斉送信だったら命令をする側は何も考えなくても良いですが、指定したところへ通信したいときは、今回はそれにあたりますが、、なんらかのIDを命令する側が把握してなくちゃなりません。

WebSocketサーバ側は、何らかのIDと、WebSocketクライアントの紐づけも持っておく必要があります。
まぁでも、DB管理しようって話はまた別の話で、WebSocketサーバが動作している限りは、言ってみればメモリ上で管理してるわけなので、そんなに面倒な話でも無いですね。

ということで、ここでは、サーバ側として、

『WebSocketサーバ と、Messagingサーバの２つをスレッドにもつプロセスを起動させる』

ということになります。
更に言えば、SocketMessagingサーバ機能は、WebSocketに限らず、命令の一次受けとして使えばよいということになります。

つづく