ネットワークの開発（データリンク層）
夕食も終わり、即座に次に取り掛かる。
プログラムは熱いうちに書けってね。
乗ってる時に書ききってしまわないと、後からなんでこうしようと思ったんだっけ？ となること間違いなし。
プログラム組んでる時は超人だけど、デバッグの時は凡人になる。
そんな感覚に陥るプログラマー諸君も多いのではないだろうか？
って、誰に語りかけてるんですかね、僕は。
ご飯食べてちょっとテンション下がったので、まずはこれまでの流れを整理。
「確かブロードキャストからだったかな」
これまで作ってたのが一対一だったのがブロードキャストは一対複数の通信だ。
これがないと宛先不明の人にデータを渡せない。
よくフリーｗｉｆｉにつなごうとしてAPを探す時なんかによく見る画面のデータ送信がそうだろう。よく知らんけど。
受信できる範囲の人にブロードキャストで、自分のＩＤや端末名を送信する。
そうすれば向こうに自分に接続するための情報を伝えられるというわけだ。
この辺はデータリンク層の分野かな？
まあハードとソフトの区別が曖昧な精霊コンピュータなので、物理層とかデータリンク層とかあんまり意味ないけど。
物理層が物理現象に依存する部分、つまり周波数だの一回の送信時間、送信出力とかの部分のことを言うとしたらブロードキャストとかはデータリンク層と言ったほうがいいかもしれない。
データを実際にやり取りする部分で物理現象は関与していないからな。
さて、詳細を詰めていくか。
「ＳＳＩＤの送信は、まあ一秒に一回とか二回とかでいいかな」
余計な通信が増えると通信速度が遅くなるし競合する可能性も高くなるしね。
確かｗｉｆｉなんかは全チャンネルをスキャンしてＳＳＩＤを収集するみたいな話を聞いた覚えがある。
そのためＳＳＩＤの送信は一秒に一〇回とか結構な頻度で発信してたはず。
こっちは共通チャンネルの上、起動キーで勝手に反応するからそんな頻度ではいらないはずだ。
携帯電話みたいに移動中とか基地局の乗り換えに対応するとなると、もう少し高頻度のほうがいいかもしれないけど、細かいところは後で調整しよう。
「まずは夕食前に考えたように専用チャンネルでＳＳＩＤだという制御コードのあと実際のＳＳＩＤや自分の固有ＩＤを送るか？」
いやいや、物理層は単純にデータ送受信に特化したい。
ＳＳＩＤ専用チャンネルは全てブロードキャスト特化にするが、あとのデータ送受信手順やフォーマットは一緒とする。
データの中身でＳＳＩＤなのか他のデータなのか分ける。他のデータを送る事があるかわからないけど。
データの帯域が二五六Ｈｚだけど、制御用コードも必要だから五一二Ｈｚの帯域が必要なのか？
送信先をブロードキャストであるゼロではなく、特定のＩＤにもできないことはないが、基本ホスト局のチャンネルに移動すればいいわけだから受け付けないでもいいんだけど、そういう用途もあるかもしれないから一応機能は残しておく。
フォーマットが同じなら処理を分けなくてもいいから処理も単純になるってことだからね。
ホスト側は物理層二五六Ｈｚ＋制御コード分の帯域ひとつと六五五三六Ｈｚ＋制御コード分の帯域複数のうち一チャンネルをサポートして、基本的に一対一か一対多で送る。端末側はどちらか一チャンネルを切り替えて使う。
これで行こう。
物理層ではもらったデータと送信先のＩＤに従って共通チャンネルか特定チャンネルで送受信する。
受信側でバッファが一杯になったら送信停止制御コードを送り、空いたら再開制御コードを送る。
エラーや競合が起こった時に自動リトライするくらいでいいや。
まずは一秒毎に一回、ＳＳＩＤを共通チャンネルでブロードキャスト送信する常駐型のプログラムを作る。
受信側は共通チャンネルで自分のＩＤかＩＤがゼロのデータを受け取り、そのまま表示するように修正。
データ帯域を二五六Ｈｚにしたりして、とりあえず共通チャンネル用の受信プログラムを作る。
その受信プログラムを残りの二台の計三台に入れて、こちらも起動させる。
「うん、ブロードキャストは正常に流れているね」
三台から一秒毎にＳＳＩＤが表示される様子を見て僕はニンマリする。
「さてこれからが問題だ」
ＳＳＩＤを四台の『パソコン』で一斉に送受信させる。
それでエラー時再送ができるか確認するのだ。
一台目は二の倍数秒、二台目は四の倍数秒、三台目は六の倍数秒、四台目は八の倍数秒でＳＳＩＤを送信する。
こうすれば二秒の時に二台が競合、四秒と六秒の時二台、八秒の時三台、二四秒の時四台が競合する。
競合した場合、信号が検知できなくなってからそれぞれ乱数で指定した分だけ待って再送を始める。
先に入られたら再び信号が検知できなくなるまで待ってまた乱数分＋して再抽選。
そこでも競合したら再度同じことを繰り返す。
二台の競合なら、二五六分の一の確率か？
台数が増えると確率が上がるが、少しずつ抜け出していくわけだから、まあなんとかなるだろう。
チャンネルを増やしてひとつのチャンネルに多数が集中しないようにすれば競合は減らせるはず。
まずは自分が送信したのとは違うデータを受信したらそこで送信は中断。
データが検知できなくなったら規定時間を待って送信するものが他にいなければ送信開始。
競合したらそれを繰り返す。
「ちょっとめんどくさいが、難しくはないな」
僕はチョチョイとプログラムを組んで、ＳＳＩＤ一斉送受信プログラムを作る。
「ぽちっとな＊４」
プログラムを一斉に動かせるように、時間指定で動かせるようにセットした後起動。
暫し待つ。
「表示順が時々前後するのはリトライしているからだな」
なんとか非同期でデータ送受信ができるようになった。
「できたのですか？」
「とりあえず、誰かが同時に話し始めたら、誰か一人だけが話すように調整して正常に受信できるようにしただけだよ」
実際にはここから、メールやグループウェア、ファイル共有などをできるようにしなければならない。
あと、電波が届く距離やエラーの影響なども確認しなければならない。
インターネットのようなデータ転送機能を入れようと思うと、まだまだ先は長い。
「うがー、めんどくせー」
すぱーん！
「うるさいです」
うぐぅ。
「叩いたね！ 父上にも叩かれたことないのに！」
「お母様には叩かれていますよね？」
「このセリフは『テンプレ』ですからね！」
「はいはい『てんぷれ』『てんぷれ』」
流された！
「まあ、いいですけど。次はもう少し競合とエラー時の対応を詰めたいですね」
データが途中で終わって終了コードが送られてこない場合とか、データが正常に送信されたかの確認はどうするかとか、まだまだ物理層やデータリンク層で考えることは多い。
まず考えないといけないのがヘッダとフッタの確実な送信だ。
ここでデータ化けやデータ抜けが発生すると、もうどうにもならなくなる。
「最初と最後だけは正常性確認するか？」
まず送るよーと開始制御コードと送り元と送り先ＩＤ、データ長を送る。
ここのバイト数は決まっているので、規定時間以内にデータが揃ったら受信側は正常受信の制御コードを返す。
規定時間内に正常受信が帰ってこなかったら再送。
規定回数再送が失敗したら、セッションを切断してバッファ内のその送信先のデータを削除する。
ブロードキャストの方は垂れ流しだね。
受信できなかったらそれまで。
ヘッダの正常受信を確認したらデータを流す。
規定の長さを送信したらチェックサムと送信終了コードを送信。
正常受信が帰ってきたら終了。規定時間返ってこなかったら再送。
データの異常はチャックサムと未受信データ位置で確認し、まずは未受信部分を再送要求。
帰ってきたらデータ埋め込みしてチェックサム確認し問題なかったらOK。
問題があったら送信バイト数を半分に減らして再送。
以下同様に繰り返す。
再送データだとわかる固有のデータＩＤもつけたほうがいいかな？
でないとどのデータが再送対象かわからなくなるかもしれないし。
「まあ、こんな感じかな」
僕はざっとエラー対応についてまとめ、プログラムを書いていく。
細かいブラッシュアップは追々やっていけばいいとして、今はハングアップしなければ上等だろう。
とりあえずこれで共通チャンネルひとつで多数の相手と通信ができるようになった。
あとはこれを通常の通信用チャンネルの六五五三六ヘルツに拡張したものを作って両方を常駐させておけば、とりあえず送受信はできるはずだ。
ほとんど一日で駆け足だったことを考えれば、ずいぶん進んだ気もするが。
まだまだやることは多い。
「……アンジェリカ、後はお願い」
子供の体力は思った以上に少ない。
電池が切れたようにとはよく言ったものだ。
いきなり眠気が襲いかかってくる。
「がく」
根を詰めすぎたせいで、意識が遠のいていく。
「アルカイト様をお運びして」
こんな時は夢の中でもプログラムを組んでるに違いない。
アンジェリカの声を夢心地に聞きながら、僕は夢の中へと埋没していった。
プログラム組んでる時は超人だけど、デバッグの時は凡人になる方、いいねをポチってくださいｗ
乗ってるときはまるでタイピングの速度より考える速度のほうが早く、途切れることもなくプログラミングすることも可能になりますが、デバッグの時に見直していると、なんでこんなことしてるんだっけ？ と思うことのしばし。
乗ってるときってコメントも書かずにひたすらプログラム書いているので、あとから見たときどうしてそうしているのか意図がわからなくなってしまうんですよねぇ。
かと言ってコメントを書きながらだと、流れが止まって、さっきまで頭の中に有ったことがすこーんと飛んでしまったり、意味のないコメントを書いてたりします。
「a=0; //0クリア」とかｗ。んなの見ればわかるんじゃー。
前のめりでプログラミングしていると、コメントとか結構適当になりがちなので、皆さん気をつけましょう。
※バイトとＨｚ取り違えているところがあったので修正。
