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

ネットワークの開発（物理層）

　前にも書きましたが、通信関係はめんどくさいです。

　グダグダ悩んでいるだけですので、面倒に思った方は適当に読み飛ばしてください。

　結論さえ押さえておけば話は通じるはずです。

　逆にじっくり検証されると、粗が見つかりそうｗ　なので、控えていただけると幸いですｗ

---

　領地へ戻った僕はとりあえず開発の続きに取り掛かった。

　こちらに魔導士爵が派遣されてくるのはまだ少し先であるし、それまでに基礎部分は強化しておきたい。

　ネットワークでファイル共有や、グループウェア、メールやチャットのようなことができれば開発効率がぐんと上がるはずだ。

　まずは王都で作った『カード』をアンジェリカに持ってきてもらう。

　いつものように『カード』床に並べて関連ごとにグループ化していく。

「うーん。とりあえずはハード面の作成と検証かな」

　王宮では複数の『パソコン』がなくてできなかったが、今は僕が王都に行っている間に組み上がったパソコンが何台もある。

　そのうち三台ほどを借り受けてネットワークの開発と実証を行う予定だ。

　流石に使用した中古は売れないので、実験で使ったパソコンは派遣されてくるだろう魔導士爵に使ってもらうつもりだ。

「まずは一対一の通信か」

　送受信は一度に送れる情報量が多いほど早くなるから、前に考えたように一度に二バイト送る方法が良さそうだ。

　六五五三六ヘルツの帯域を使って一度に二バイト送る。

　ただこれだと、実データと制御用のデータの区別をどうするかという問題が出てくる。

　これがシリアル通信だとスタートビットやストップビットなどという仕組みでデータの開始と終了を制御していたはず。

　最初の頃のデータ転送もその方式を採用していた。

　同じような仕組みを入れておかないとどこが最初のデータか判別ができない。

　なのでゼロから六五五三五＋制御コード分の帯域を使って六五五三六だったらデータ開始、六五五三七だったらデータ終了などといった意味をもたせることで、開始位置と終了位置が簡単に判別できるように考えてみた。

　制御用コードはとりあえず一バイト分、二五六Ｈｚもあればいいか。

　それ以上が必要になったら二回三回とか分けて送ればいいし。

　次に決めるのが送受信のデータ長をどうするかだ。

　パケット化することは決定だから、ひとつのパケットを固定とするか、可変とするか、可変とするなら最小値最大値はどうするか？

　パケットにはヘッダやチェックサム等のエラーチェックデータを入れるため、小さすぎれば効率が悪くなるし、大きすぎれば通信エラーが出やすくなったりリトライなどで専有時間が長くなる。

　固定長だと小さなデータを頻繁にやり取りする場合は無駄が多くなる。

　やはりここは可変長データにするか。

　データ長バイトを一バイトにすると、一度に二五六バイト長までしか送れないからなんか小さすぎる気がする。

　データバイト長を二バイト六五五三六バイトを最大にするか。

　データエラーが頻繁に起こるようならデータ長を短くするようにして。

　実際には一パケットを一回の送受信で送る必要もないので、パケットサイズに拘る必要はないのだが、分割したりくっつけたりする処理が頻繁に起こると処理時間が通信に取られてしまうので、できるだけ余分な処理は省きたいところだ。

　データを無加工で送受信できればそれだけ効率がいいからね。

　でも結局通信状況が悪いとパケット長が調整されるわけだから、あまり拘る必要もないかな？

「うがー、めんどくせー」

「突然奇声を上げるのはおやめください。今更ですけど」

　脇で控えていたアンジェリカが抗議の声を上げた。

「わかってるならいわないでよ」

「わかってても言いたくなるくらいびっくりするので、控えていただけると助かります」

「前向きに善処します」

「……はあ、相変わらず善処するつもりはないのですね」

「僕が言うのもなんですが、諦めたほうが早いですよ？」

　こっちは中身爺だぞ？　今更そうそう変えられるか。

「前向きに善処します」

　お主やるな。そう切り替えしてくるとは。

「この話題は不毛なのでやめましょう」

「そうですね」

　合意に達して何より？

「とりあえずやれるところからやってしまいましょう」

　データ長は可変で最大六五五三六バイト。

　ヘッダーには送信元アドレスと送信先アドレス、それにデータバイト長を入れておこう。

　送信元と送信先アドレスはパソコンにあらかじめセットされている固有のユニークIDを使うことで、どのパソコンからどのパソコンへ送信するかを判別する。

　同じ周波数帯をシェアする可能性もあるのでどこからどこへ向けての通信か判別できるようにする必要があるだろう。

　フッタにはチェックサムでいいだろう。

　周波数変調でまとめて二バイト送るのでビット化けなんてのは考えなくてもいい。

　考慮が必要なのはデータ抜けだな。

　データが一回分まるまる抜けるとかの可能性もあるけど、指定バイト数の送信が終わるまで常に判別できるデータが来るはずなので、一定時間データが来ない場合そこがデータ抜けとわかるはずだ。

　信号ON－OFFしかないシリアル通信と違って、常に基準周波数＋送信データの周波数で電波が飛んでいるから、開始と終了の制御コードさえ受信できれば、その間に何個のデータが飛んできたか判別できる。

　抜けた場所がピンポイントでわかるから再送要求もそこだけに絞ればリトライにかかり時間も少なくて済むかもしれない。

　開始か終了とかが抜けちゃうと終わりだけど。

　まあ、細かいことは後で考えるとして、ざっと通信できるようにしてみるか。

　エラー訂正とかはひとまず後回しにして、特定の長さでの送受信プログラムを作成し、二台のパソコン間で送受信できるか確認してみよう。

　一秒間に何バイト送れるかも確認しないといけないし、送受信だけで全部の処理能力を使い切るわけには行かないからせめて通信で使える処理能力は二〇%～三〇%くらいに調整したい。

「通信関係は最低限でさえめんどくさいな」

　まあ、粛々とやっていきますか。

　まずはベースとなる周波数を決定。

　八〇〇メガヘルツでいいか。

　携帯ではプラチナバンドと言われている周波数帯だ。

　向こうでも実績のある周波数帯だし、将来的に携帯網を作るときのことを考えてこちらでも実績があったほうがいいだろう。

　どうせソフトウェアを書き換えれば周波数なんていくらでも変えられるからね。

　対応バンドがどうのこうのなどは考える必要はない。

　通信速度はとりあえず１０BASEのイーサネットを目標にしてみようか。

　いわゆる一〇メガＢＰＳなので一六ビットで割るとざっと一秒間に六二万五〇〇〇回処理しなければならない。

　まあ、送信側は送信データに合わせて送信周波数を変更して送信済みデータポインタを変更するだけなので、問題ないだろう。

　受信側は起動キーを六五五三六＋二五六分登録しておけば、そのデータが来た時に反応させることができるけど、チャンネルが増えるとその分登録が倍数で増えていくんだよなぁ。

　今のメモリー量があればその程度は問題ないと思うけど。

　チャンネル切り替えした時に定義を書き直すようにすればいいか。

　ＳＳＩＤとか全チャンネルスキャンが必要なやつは、どうしようか。

　特定の制御コードだけ起動キーで監視しとけばＳＳＩＤが来たのはわかるけどデータの受信が他のチャンネルだからできない。どうしたもんか。

　後問題は電波が出続けている限り反応しちゃうことか。

　これは特定周波数の電波を一定時間以上受信したら反応するようにキーを設定すればいいかな？

　僕はとりあえず基本的なパラメータを決めて送受信プログラムを作成していく。

　電波を出すところは画面表示と一緒なので問題はない。

　定期的に割り込み入れてデータに対応した周波数の電波を送信するだけだ。

　基礎部分ができたら今度はテストプログラムを組む。

　適当なソースコードを一行ずつ送るプログラムだ。

　一行送るたびにヘッダとフッタをつけて送り出す。

　一行が六四キロバイトも有るようなテキストはないから、データが分割されることもないので処理としては単純なもので済む。

「まあ、こんなものかな」

　一時間ほどでとりあえず想定していたレベルまで達した。

「受信プログラムをこっちで起動してっと。ぽちっとな」

　ターゲットとなるマシンで、受信プログラムを起動。

「んで、送信側も起動っと」

　送信が始まると受信側でソースコードが表示され始める。

「おー、行けるいける」

　案外いけるな。

　とりあえず送受信に問題はなさそうである。

　チェックサムに異常があると赤く表示されるようにしてあるがとりあえずは出ていないようだ。

「これだと負荷状況がわからんなぁ」

　タスクマネージャーがあるわけじゃないから、どの程度処理能力に余裕があるかわからない。

　しかも今は送受信以外、画面表示しかしていないからね。

　もっと重い処理を入れれば受信側が追いつかなくなる可能性がある。

　送受信は全部割り込み処理なので定期的に処理されるが、バッファが一杯になったら送受信は停止する。

　どうせバッファフルになったら送信側に停止信号を送って送受信が停止するんだから、ある程度負荷は高めでもいいのか？

　その場合はフォアグラウンドの処理がカクカクするけど。

　まあ、その時は送信速度を調整すればいいか。

　次は送受信の双方向化だな。

　今の状態だと自分が送信したデータを自分が受信しちゃうからね。

　最新の送信直後に受信したデータと送信データを比べて同じだったら破棄する他ないか。

　起動キーを送信するたびに書き直していたらとんでもない時間がかかる。起動キーはインクで書かないといけないからね。

　それとＩＤが自分でない場合やデータが構造的に破綻している場合も破棄だ。

　今は同じチャンネルをシェアしていないからいいが、複数マシンが通信を始めると必ず同じチャンネルを使うやつが出てくる。

　かといって、一台のマシンから同期信号を常に出すのは非効率だ。

　突然割り込んでくるやつが出てこないとも限らないし。

　データ送信はできれば非同期にしたい。

　同期しようと思うと誰かが音頭を取る必要があるからね。

　非同期の場合、誰かが通信を始めた場合、他のマシンは待機することで回避できるだろう。

　完全に同タイミングだとしても、自分が送信したデータと違うデータを受信したらデータ送信を停止すればいい。

　再送は回線が空いたら乱数値で決まった時間待ってから再度行えばいいだろう。

　乱数で送信タイミングを二五六個用意すればそうそうかち合うこともないだろうし。

　そうそう、忘れてた。

　ブロードキャストができないとまずいな。

　ヘッダに送信元と送信先ＩＤを入れるようにしているけど、ここの送信先ＩＤがゼロなら全端末向けの送信ということにしよう。

　ＩＤゼロは今の所存在しないし。

　これで無線ルータのＳＳＩＤみたく自分のＩＤを送信できる。

　ＩＤを定期的に送信するようにすれば近くにどのマシンがいるかわかるからね。

　ただ今のままだと同じチャンネルのＳＳＩＤしか検知できないな。

　向こうのｗｉｆｉだと順番にチャンネルをスキャンしていくんだったかな？

　でも精霊コンピュータはそんなに頻繁に起動キーを書き換えられない。

　ならＳＳＩＤとかの全チャンネル向けの場合は専用のチャンネルを用意するか。

　帯域を二五六Ｈｚ＋αとかに制限すれば起動キーも少なくて済む。

　ＩＤがわからないと直接自分で調べて入力するしかないが、この方法ならＩＤを自動収集できるし負担も少ないだろう。

　ＳＳＩＤのブロードキャストが不要な時はデータを捨てるか。

　データが来るたびに割り込みはいるけど、送信頻度を低くすれば負担も少ない。

　まてよ。

　ＳＳＩＤが必要なのは最初の接続のときだけだから、不要になった起動キーは削除すればいいんじゃね？

　必要なときだけ起動キーを設定して不要になったら消す。

　どうせ接続する際はホストになるチャンネルに移動しないといけないわけだし。

　これなら変に反応して処理に時間を取られることもないだろう。

　ホスト側はＳＳＩＤを受信する必要がないから受信の起動キーはそもそも不要だし。

　よし、これを入れればとりあえず物理層？　は完成だ。

　すぱこーん

「あたっ！　なにするんですか？　アンジェリカ」

　久々に食らった『ハリセン』。

「夕食の支度ができたそうです」

「口で言ってくれればいいのに」

　僕は恨みがましく振り返った。

「何度もお呼びいたしました。なんならもう一度喰らいやがりますか？」

「いえ、結構です。続きは夕食後ですね」

　僕はそこで作業を切り上げ、食堂に向かった。

---

　インターネットの詳しい話は検索すればいくらでも出てきますので、気になる方はそちらを参照願います。

　殆どの方はインターネットとはどういうものか漠然とわかっていても、その仕組までとなると知らないことのほうが多いかと思います。

　主人公も大雑把にこういうものだと知っていても、詳しくは知らないので、少ない知識と試行錯誤でなんとかしようと奮闘します。

　作者も同様ｗ　なので、色々試行錯誤して、その試行錯誤の過程を作中に反映しています。

　主人公の苦労は作者の苦労と同等であると考えていただければ幸いです。

※バイトとＨｚ取り違えているところがあったので修正。