通信の効率化
サーバ連携はとりあえずこれでいいとして。
それより自分以外のパケットの効率のいい除外方法だ。
最初にパケットヘッダが飛んできて宛先が自分でなかったら後のデータは捨てる。
捨てると言っても起動キーは反応するので、割り込み処理が走る。
パケットが飛べば飛ぶほど割り込みが走るので負担が大きくなるというわけだ。
何もしていないのに、処理が走るのはうまくないよね。
何とかこれを走らせなくする方法はないだろうか？
「とりあえずチャンネルを細かく分けることで、割り込みを少なくすることはできる」
しかしこれには問題がないとは言えない。
二チャンネル同時受信した場合、起動キーが同時に起動条件を満たしてしまうことだ。
割込み禁止していないので、先に受信したほうが待たされるだろうが、処理能力的には問題ないはずだ。
一チャンネルの受信で能力の二〇パーセントくらいしか使ってないからね。
でも二チャンネルで四〇パーセント、三チャンネルで六〇パーセントだからここまで来るとちょっと心もとなくなる。
しかも一チャンネル一バイトにデータ速度を落としてしまうと、通信時間が二倍になるわけだから、受信処理に取られる処理能力は結構馬鹿にならない。
パケットヘッダで自分宛てでないとわかってから起動キーを消し、次のパケットヘッダが来る直前に書き戻すなんてことはできようはずもない。
プログラムエリアへのき込み速度は激遅だからだ。
ならどうすればいいか？
「物理層を適当に決めたのがここに来て足かせになっているな」
ここで一番のネックになっているのはブロードキャスト送信だ。
全員に同じデータを送るためには、みんなが同じチャンネルにいる必要がある。
「まてよ。電話ならともかく、メールサーバならブロードキャストはいらないんじゃないか？」
確かに全メールサーバにデータを一度に送れれば便利だ。
同報通信だって一度の送信で済むわけだし。
しかしメールは届いたことを確認する必要がある。
音声なら多少抜けてもいいが、メールに抜けは許されない。
まあ、サーバの不調とかで、たまには消えちゃうメールもあったりするけどね。
たとえブロードキャストで送信したとしても個別に到達確認はしないといけないだろう。
ならば常に個別配信してもいいんじゃないだろうか。
基地局および基地局につなぐスマホやパソコンの受信チャンネルはすべて別チャンネルに指定。
送信側で対応する機器のチャンネルに送ってあげる。
これなら受信するのは自分宛ての電波だけに限定できる。
本当にこれで問題ないか考えてみよう。
まず問題はスマホやパソコンをすべて別チャンネルに設定できるかだ。
１ＭＨｚで約三三〇〇チャンネルが割り当てられるから、当面は問題ない。
近距離帯用なら高周波帯が使えるから１０ＭＨｚとか平気で使える。
しかし念の為、ある程度シェアできるようにしといたほうがいいかな？
例えば基地局毎に１ＭＨｚを割り当てる。最大三三〇〇チャンネル×二五台のスマホが接続可能だ。
ＳＳＩＤは近距離帯の全共通チャンネルで流れる。
ＳＳＩＤには基地局の受信チャンネル情報が含まれているので、パソコンはそこへ送受信チャンネルを切り替え、基地局に向けて接続をリクエストする。
基地局は認証処理が問題なければ自分の割り当てられた周波数のうち、未割り当てチャンネルをパソコンに向けて指示する。
パソコンは指示されたチャンネルで待ち受ける。
一チャンネルに一台しかいなければ、同時送信を検知する必要もないから送信チャンネルはチェックする必要がない。
離れた基地局は同一チャンネルを使っても問題はないから、実際上問題のないくらいの端末をぶら下げることができるはずだ。
では逆はどうだろう？
パソコン側からは基地局チャンネルにパケットを送るわけだが、送ってくるやつは複数いる。
「だめじゃん」
同時送信を回避する必要があるけど基地局チャンネルはウォッチしていない。
「自分と基地局のチャンネルをウィッチしたらどうだ」
二チャンネル分だと確かに負荷は大きくなるが、自分向けのチャンネルはそもそも無駄な受信じゃないし、個別のパソコンに負担がかかるだけなら、基地局に負担がかかるよりずっといいしね。
「とはいえ自分が基地局向けチャンネルでパケットを送信する時以外不要な受信なんだよなぁー。何とか負担を減らせないものか？」
ちょっと考えてみよう。
基地局向けチャンネルへのパケットは基本的に基地局以外には不要なパケットだ。そのための専用チャンネルだからね。
使用するのは最初の認証のときだけだし、必要なのは誰かが送信しているかどうかを確認するときだけだ。
「例えば送信終了コードだけに反応したらどうだろうか？」
送信開始や送信終了時には特定の制御コードを発送する。
終了から開始までの間は当然パケットが飛んでいないことがわかる。
問題は終了コードが受信できなかったときだ。
誰も送受信していないとパケットは飛ばない。
空いているのか、単に受信できなかったのかがわからない。
「その時は一パケットの最大時間分待って終了コードが飛んでこなかったら通信を初めちゃえ」
どうせかち合ってエラーになったら再送するわけだし。
終了コードと開始コードにだけ反応するのであれば起動キーによる割り込みは大幅に減らせるはずだ。
接続チャンネル分起動キーを設定しても１チャンネル三〇〇台接続しても起動キーは六〇〇。
二バイト受信だと六五五三六＋制御コード分起動キーを登録していたのに比べれば屁でもない。
「いける！」
基地局の近距離チャンネルで不要なパケットが飛ばなくなった分、長距離チャンネルの負荷が多少高くなっても問題ないはずだ。
まあ、基地局同士の通信はそのうち飽和するから、いずれ考える必要があるけど、負担が減った分基地局が増やせる可能性もあるし、溢れそうになったら考えよう。
認証情報をやり取りする際のブロードキャスト通信さえなんとかすれば何とかなる気がする。
根本的な問題はブロードキャストなんだよねぇ。
パケットを全員が受け取らないといけないので、そのチャンネルは繋ぎっぱなしにしないといけない。
かと言って全部別チャンネルにすると、全てを個別に何度も送る必要がある。
ブロードキャストチャンネルと個別チャンネルを設定したらどうだろうか？
そうすると近距離一チャンネル長距離二チャンネルの三チャンネルを同時にウォッチすることになるが、共通チャンネルで飛び交うパケットが少なくなればそれだけ基地局への負担も軽減できる。
要は不要なパケットでも受信しちゃうから無駄に負担が大きくなるのであって、必要なパケットだけ受信するのであればその負担は正当なものになる。
とりあえず基地局と端末はこんな感じで考えてみよう。
各端末へのブロードキャストはＳＳＩＤチャンネルだけだし、こちらは頻度が少なく近距離チャンネルだからご近所とかち合う可能性は少ない。
各端末から端末へのブロードキャストは音声通話時だけに限定。
電話は空いている適当なチャンネルに移動してのブロードキャストだが、そこに多数のユーザーが密集しない限り問題はない。
密集してたら再移動すればいい。
メールサーバは電話と同じようにユニークな近距離チャンネルで基地局につなぎ、メールデータを送る際はその基地局につながっているメールサーバとネゴして、チャンネルと暗号キーを入手して直接データを送る。
メールサーバはその後、各宛先毎にメールサーバとネゴって順次基地局サーバを経由して送付する。
これならメールサーバも一チャンネルの待受で済む。
「まてよ。メールサーバはユニークな長距離チャンネルでもいい気がする」
考えてみよう。
基地局サーバ同士や認証サーバとは長距離チャンネルでやり取りするのだ。
メールサーバとて長距離チャンネルでいいんじゃないかな？
というか認証サーバとメールサーバは一緒でいいんじゃね？
もとい一緒のほうが都合がいい。
メールのユーザーＩＤとパスワードが電話でも使われているし、メール登録したら電話も使えるほうがいい。
どちらかの登録と一緒にしたら通信が一回減らせるわけだし。
なら電話サーバのほうがいいかな？
電話サーバは今の所ネゴにしか使わないから処理能力は余っている。
それならスマホ＜ー＞基地局＜ー＞基地局＜ー＞認証サーバのうち認証サーバへの通信がカットできる。
どうせなら、メールサーバも一緒にしたらどうだろう？
メールは一旦基地局に保管される。
そこからユニークな長距離チャンネルを使って各サーバへ送られる。
そもそも一チャンネルで多数の関係ないパケットが飛び交うから無駄な処理能力を使うので、自分向けの通信しか来ないのであれば、能力に余裕は出るはずだ。
複数のサーバ機能を一台にまとめても能力としては問題ないはずだ。
問題はマルチプロセス機能が未実装ということだね。
まあ通信系だけはマルチで動くしサーバ自体は表示が必要ないので、マルチ処理が必要なのはファイルアクセス系か。
電話のネゴはデータ転送だけなのでファイルアクセスはなし。
認証系はファイルの読み書きが必要。
メールも読み書き必須だ。
ファイル読み書きだけでもマルチ対応しないとサーバが建てられない。
「マルチタスクやマルチプロセスはめんどくさいんだよなぁ」
なにせ精霊にはプロテクトモードとか仮想モードなんてものは存在していないからね。
さてはてどうしたものか。
「本格的な販売開始までになんとかしたいけど、まにあうかなぁ」
売った後アップデートということも出来ないわけじゃないけど、電話サーバ＆メールサーバを売った後、一つにまとめられますなんて言ったらどやされるだろうし。
複雑な処理だと時間がかかるのなら、簡単にするにはどうしたらいいか考えてみよう。
そもそもサーバＯＳなんて必要な機能が限定されているから、ＷＩＮＤＯＷＳのような巨大で複雑な機能は必要とされていない。
必要最低限の機能だけマルチ対応していればいいはずだ。
まず表示はマルチ対応不要だ。
必要なら各サーバアプリごとに別画面を作ってもいい。
この辺は今のＯＳでも対応している。
電話で着信画面出すのもこの機能だね。
キー入力はアクティブウィンドウという考え方がないから、メイン画面のみに反応するが、それで問題ない。
メイン画面ではメンテナンスツールしか動かさないからだ。
メンテナンスツールは例えばダウンロードサーバへのアップロードとか、不正メールの確認とか設定の変更の時に使われる。
サーバ機能を止めてからでもいいのだが、できればノンストップでいきたい。
とすると認証サーバの認証情報を追加したりなど、ファイルの排他処理が必要になる。
「めんどくさいでござる」
単純化してもめんどくさかったよ。
「まてよ。サーバ機能に更新機能つければいいんじゃね？」
別のアプリからファイルアクセスするからめんどいのであって、常にひとつのアプリからアクセスすれば面倒はなくなるはずだ。
「いけるか？」
追加する機能は増えるが、マルチアクセスよりは簡単なはずだ。
セマフォだのクリティカルセクションだのデッドロックだの考えるよりずっとわかりやすい。
しかもこれならファイルを更新するだけじゃなく更新したファイルで再設定することも瞬時に行える。
外部からファイルを弄るとそれを再度読み込まないと再設定ができないけど、設定をコマンドで変更できるなら内部設定を変えてからファイルにバックアップという形になるから、設定の反映が先にできる。
「うん、この線で書き換えてみよう。間に合わなければ、しばらくは先行テスト期間として、デバッグに協力して貰う代わりに少し割り引くなりキャッシュバックするなりすればいいや」
文官にも現状を報告して、了解をもらう。
少なくとも新麦の入札までにお金を用意しないといけないから、販売時期は待ったなしだ。
おお、なんか修羅場ってきたな。
「久々の『デスマーチ』、はっじまるよー」
すぱこーん！
「痛い！ なにするんですか？ アンジェリカ」
「もうお休みになる時間です」
「いや、しかし、時間が……」
すぱーん！
「いたっ、くないけど痛いよ」
「駄目です。お休みの時間です。『ぱそこん』は持ち込み禁止です」
「はーい」
鬼の監視役には逆らえない。
全部母上のところに報告が行くからね。
仕方ない。スマホを持ち込んでベッドの中でやればいいだろう。
ちょっと打ちづらいけど使えないわけじゃないし。
「もちろん寝室への『すまほ』の持ち込みは禁止です」
なんですと。ばれてーら。
「しかたありませんね。置いていきますよ」
僕はスマホを一個机の上に置く。
「まだ持っていらっしゃいますよね？」
「いえこれだけですよ？」
「アルカイト様、ちょっと跳ねてみていただけますか？」
ハリセンをぱしぱししながら跳ねてみろとか、どこのスケバンのカツアゲですか？
「はーい」
仕方なく数度ジャンプ。
「こっちになにか入ってますね」
ああ、それは。
ズボンのポケットに手をツッコミ、取り出されたスマホ。
僕が成人してたら立派なセクハラですよ？
「もう持っていませんね？」
「はぁ、もうありませんて」
「まあいいでしょう」
僕は付け足しとばかりに小さな声でささやく。
「それ『ＦＣＳ』入ってるやつだから慎重に扱ってくださいね」
「承知いたしました」
アンジェリカはすべてのパソコンとスマホを設置してある金庫にしまい鍵をかける。
「では寝室へ行きましょう」
僕の最強の武器『ＦＣＳ』を取り上げられた以上、普通の子供以下のステータスしか無い僕では、逆らいようもなくおとなしくドナドナされていくのであった。
マルチタスク処理ってリアルタイム処理を行おうとするとたいてい出てくる憎いアイツ。
リソースが完全に分かれていればさほど面倒はないのですが、同じリソースを複数のタスクで共用しようとすると、どこが何を使っているかきちんと把握した上で排他処理とか必要になります。
一箇所でもそれを怠るとなにやら分けのわからないことに。
しかもどこで競合が起こっているかわからないという地雷付き。
マルチタスクのデバッグは地獄です。
さらに複数リソースを複数タスクで使っていると、稀によくあるデッドロックに。
これを解決するたったひとつの冴えたやりかたは、リソースを全部自分が奪っちゃえばいいｗ
お前のものは俺のもの、俺のものは俺のものというジャイアンプログラムこそが答えなのです！
ＤＯＳの時代は基本的に全リソースが使えたのでジャイアンでも良かった。
今の主人公のパソコンもＤＯＳレベルなので、ジャイアンしちゃいますｗ
※誤字修正。
ズボ[ん]->ズボン
