異世界のジョブズに、僕はなる ～定年SEの異世界転生業務報告書～

電話アプリの改良

　アップデータが割と簡単にできたので電話アプリについて今一度考えてみる。

　今のままだと、一チャンネル一サーバ五〇端末が基本になる。

　内線ならともかく外線でこの数値はちょっとなあ。

　まあ、向こうの世界の電話だって、最初の頃は一部地域でのサービスのみで、電話網なんか大して整備されていなかったし、電話をつなぐのはもっぱら交換手が手動でケーブルをつなぐという大変原始的なものだった。

　それに比べれば僕の電話なんてハイテクといっていいくらいの進化だ。

　しかし、この方式の欠点はこのままだと発展性に乏しいということだ。

　パソコンの性能が上がれば、伝送速度も上げられ、一チャンネルを流れるパケット量も増えるから、ぶら下げる端末は増やしていけるだろうが、そのうち限界が来る。

　今のうちになんとかしたいところである。

「実際のところ、『電話サーバ』は最初のネゴしか使わないから、処理能力は余っているんだよなぁ」

　元々音声データを中継させるつもりだったのが、トランシーバー方式、つまりネゴった後はそれぞれが勝手に通話を始める。

　そこにサーバは介さないのだ。

　まあ、同じチャンネルを使っているから、受信割り込みによる処理は発生するけどサーバは普通のより四倍早いから他と比べて五分の一の負担にしかならない。

　通常の端末における通信処理の割合は全処理の二〇%くらいだからね。

「無駄に余った能力をなにかに使いたいところだけど」

　メールサーバと共有するか？

　しかしそれはあまり上手い手ではない。

　メールサーバはリアルタイム性を必要としない上、ＨＤＤへの書き込みという遅い処理が結構負担になっている。

　同報通信などで複数人に同じメールを出すと同じデータを何回も書いてしまう。

　同じデータならどこかひとつに書いてリンクすればいいような気もしないでもないが、全リンクが切れるまで保持とかめんどくさかったのでそのままだ。

　メールサーバは負荷が大きくなったら通信を一時的に止めて、メーラーを待たせることができるが、電話サーバでこんなことをしたら、いらっとすること請け合いだ。

　まあ、ネゴだけなら待たせてもいいのか？　いや、最初の呼び出しが遅いだけでもイラッとするか。

　電話ってリアルタイム性を求めているからね。

　なら電話機能になにか付加できないだろうか？

　一番欲しいのは、一チャンネル五〇端末のクラスター同士を接続する機能だ。

　複数の電話サーバをつないでどこのクラスターに所属しているか判断して、そこにネゴデータを転送できないだろうか？

　クラスターとそれぞれのユーザーの所属クラスター一覧があれば、サーバ同士でデータ転送ができるはずだ。

　その場合、クラスター内の通信と、サーバ間の通信の二チャンネルを使うことになるから、サーバの負担は二倍になるが、そもそも処理能力は余っているのだから問題ないはずだ。

　問題はサーバ同士の通信でも一チャンネル使うわけだから、ここの通信量があふれると、それ以上はサーバを繋げなくなる。

　例えば電話と同じ五〇台でパンクしたとすれば、五〇×五〇で二五〇〇台まで管理が可能になるはずだ。

「通話と違ってネゴ自体はそんなにパケットを必要としないから、もうちょい行けるか？」

　まあ、このへんはやってみるしか無いか。

　そんなに端末がないからテストは出来ないけど。

「しかしなぁ。五〇台で一サーバ使うのももったいない気がする」

　しかも使うのはネゴだけで、チャンネルの通信が飽和したら処理能力が余っていても、それ以上は処理できない。

「他に手はないだろうか」

　僕は引き出しから紙と鉛筆を出して、図式化してみる。

　視覚情報というのはアイディア出しにはもってこいだからね。

　えっと、クラスターがいくつかあって、クラスターとクラスターを管理するサーバ同士がデータをやり取りしてネゴる。

　ネゴり終わった端末は、送信側のクラスターに移って相互に通信し始める。

「あっ！　クラスターを移ったら五一台が同じチャンネルで会話を始めちゃうじゃん」

　やばい。

　とするとサーバが中継して、チャンネル間のギャップを埋める？

「いやいや。そんなことをすればサーバ間通信があふれるし、それらのデータを転送し始めればサーバの処理能力も飽和する」

　詰んだ。

　改良案を考え始めた途端に詰んじゃったよ。

「いやいや、僕たちの戦いはこれからだ」

　諦めたらそこで試合は終了だ。

　諦めなければ答えが見つかるはずだ。

　たぶんね。

　最善とは行かないが十分妥協できるレベルくらいまでは持っていきたい。

　まず前提条件を確認しよう。

　通常の電話だとネゴりは必要だ。

　暗号キーを交換して、通信を始める。

　トランシーバーモードだと、ネゴを省略する代わりにあらかじめグループ名とパスワードを設定しておく。

　あとはブロードキャスト通信で通話を始める。

　どちらにしろ待受は特定のチャンネル固定にしないと、信号が受け取れないことになる。

　複数回線をウォッチすると処理能力が飽和するし。

「まてよ。ネゴが終わったら別の回線に移動してもいいんじゃね？」

　これを人間に例えてみよう。

　大きな部屋に全員を押し込め、話したいやつを見つけたら別の部屋に移動する。

　これなら一台のサーバで多数をコントロールし、チャンネルが飽和する可能性も少ない。

　人を探すとき以外みんな無言だからね。

「問題はどうやって空きチャンネルを見つけるかと、その空きチャンネルで通話が可能かどうやって確認するかだ」

　例えば長距離チャンネルで、ネゴる。

　しかしその場合誰がどこにいるかを把握していないと近距離チャンネルには移行できないから、すべての通信は長距離チャンネルで行わないといけなくなる。

　しかし長距離チャンネルは帯域が狭い。

「チャンネル増やせばいけるんじゃね？」

　一チャンネル二バイトだと１ＭＨｚあたり一五チャンネルくらいだけど、一バイトにすれば三三〇〇チャンネルくらい作れる。

　回線速度としては半分になるが、一グループだけなら回線速度としては十分間に合うはずだ。

　いや、五〇端末の半分、二五端末分の会話なら行けるだろう。

　つまり１ＭＨｚで八二〇〇〇台以上の端末が会話できることになる。

「これなら行けるか？」

　どこかに落とし穴がないか考えてみよう。

　まず問題は、空きチャンネルの把握だ。

　これは電話サーバが把握している？

　いや、ネゴった後空きチャンネルに移動したら、その後の追跡ができないから通話が終了したかどうかわからない。

　そうなるとどうやって空きチャンネルを探せばいい？

　電話を切った時に切ったよ信号をサーバに送るか？

　しかしこれは信号が届かないとそのチャンネルがずっと使いぱなしってことになってしまう。

　そうすると実際に空きチャンネルをスキャンして使用率を計測するしか無いか？

　しかしチャンネルスキャンはできれば避けたい。

　まずやるとすれば一チャンネルごと起動キーを書き換えてスキャンする方法だがこれは魔導板の書き換えが頻繁に発生するので、１ＭＨｚの帯域にある三三〇〇チャンネルをスキャンするだけでも大変な時間がかかるし、インクも大量に使用してしまう。

　あらかじめ全チャンネルの起動キーを定義しておくと、全チャンネルの通信で割り込みが入ってしまうので、その割り込み処理だけで処理が飽和してしまうだろう。

　さて困った。

　めんどくさいから乱数で適当に選んで、混み合ってきたらまた移動するとかでいいかな？

「まだ端末も少ないしそうそうかち合うこともないだろう」

　頻繁にかち合うようになってから考えても遅くない。

　まあ、ネゴが終わって、チャンネルを移動した後、誰かいますかパケットをブロードキャストで飛ばして、何人から返事が来るかを確かめて、既定値以上だったら、移動するよパケットを流すとかの方法もあるか。

　面倒だから電話が増えたら考えよう。

　そのときにはぜんぜん違う方式になっている可能性もあるからね。

　まずは今必要なことを考えてみよう。

　回線数の問題は何とか解決しそうだけど、電磁波の問題はどうするかな？

　この方法だと全て長距離通信になっちゃうから、スマホからの出力がとてつもなく大きくなってしまう。

「まあ、最初は大電力で、エラーが発生するまで徐々にパワーを落としていけばいいか」

　エラーが出たらパワーを上げて、エラーが無くなったらパワーを下げる。

　あまり頻繁にやるとエラーとノーエラーを繰り返すから、しきい値を設けて、ノーエラーが何秒以上続いたらパワーを下げる、エラーが何回以上出たらパワーを上げるとかすればいいだろう。

　今も一応自動調節が付いてるけど、洗練されているとはいい難い。

　この辺りはデジタルと言うよりアナログの部分だから、調整作業は職人芸となりそうだ。

　まあ、状況を見てゆっくり調整していけばいいだろう。

　後問題になりそうなのは、完全トランシーバーモードだね。

　基本的に全端末はネゴチャンネルで待っている。

　そこでいきなり全端末向けに勝手にネゴられると困るよな。

　全端末から常にネゴパケットが飛んでくる可能性があるのだ。

　そんな中で勝手にネゴられたらネゴチャンネルがパンクしないだろうか？

　サーバを通す場合最初のネゴパケットは任意のタイミングだが、そのネゴパケットを相手先に転送するのは、一パケットづつだから、飛び交うパケットはネゴり始めた端末数＋宛先数だ。

　これにトランシーバーがネゴり始めると、グループ内ユーザー数のパケットが飛ぶことになる。

　これって結局はネゴサーバが複数起動しているのと同じことだよね？

　大量にトランシーバーモードで始めるやつが出てくると、パンクしそうな予感がする。

「トランシーバーモードは外しちゃおうかな？」

　普通の電話だって複数人での音声通話もできるんだから、なくてもいいよね？

　それよりネゴサーバは複数台を連携できるようにしたい。

　端末が増えてくるといずれチャンネルはパンクするからね。

　今は不要だけど、環境だけは整えておいたほうがいいかもしれない。

「決めるのは周波数帯と、チャンネル数それから、一バイトデータにするか二バイトデータにするかだ」

　二バイトデータにすると速度は二倍だが必要な帯域は二五六倍だ。

　効率が悪すぎる。

　まずは一バイト分の帯域で１ＭＨｚ分確保すればとりあえず問題ないだろ。約三三〇〇チャンネル分だ。

　ここは電話サーバとメールサーバ、アップデートサーバなどのサーバ用にするか。

　複数サーバの連携用にこれだけ確保しておけばまず足りなくなるということはないだろう。

　あとはネゴった後の通話帯も隣り合った１ＭＨｚを使って同じく三三〇〇チャンネル用意する。

　今の段階ではこれで十分なはずだ。

「よし、この線で『サーバ』と『アプリ』を書き換えてみるか」

　とその前に、文官にメールだ。

　もしかしたら台数制限、距離制限が撤廃いや、緩和されるかもとの事前情報を流しておくか。

　数量限定と言っておきながら手のひら返しだと詐欺と言われても仕方がない行為だし。

　まあ、本当にとりあえずは数量限定で、しばらくしてからのアップデートで使えるようにしてもいいんだけどね。

　そのへんどうするかも文官と父上に丸投げしよう。

　僕は粛々とプログラムを作るだけだ。

---

　二転三転する通信関係。

　本当にめんどくさいです。

　できるだけ簡単にかつ多回線同時通話を実現するにはどうすればいいか。

　どこまで魔法に頼って、どこまで魔法を排除するのかとか、多分主人公の何倍も悩みましたｗ

　魔法で解決ってなると話は早いんですが、それは単なるチートで、知識チートじゃない。

　知識チートを名乗るにはそれなりに知恵を絞らんといかん、と頑張っては見たものの皆さんに伝わっているといいのですが。