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

メールアプリの開発

　さて、データ通信の目処が立ったところでメールでの流れを考えてみよう。

　データ通信は手段であって目的ではない。

　目的はメールだったりチャットだったりファイル共有やグループウェアを作ることなので、データ通信はそれらアプリが必要とする機能があればいい。

　使わない機能ならいらないし、必要な機能を実現するためにデータ通信側に手を入れないといけない可能性もある。

　なので次は実際に使うアプリについて考えてみる。

　まずはビジネスでよく使うメールから考えていこう。

　メールのやり取りに必要なのはメールサーバだ。

　直接相手先のパソコンとやり取りできないわけではないが、相手が遠方にいたり接続を切っている可能性もあるので、それを仲介するサーバは必須だろう。

　向こうだと接続方式はＰＯＰ３やＩＭＡＰ、ＳＭＴＰ等があるが、細かな規約はともかく同じような考え方でいいか。

　送信側は送るだけだからまあいいとして、問題は受信側だ。

　受信はむこうでもＰＯＰ３とＩＭＡＰと二方式有るように、こちらでもどちらかを選ばなければならない。

　ＰＯＰ３は簡単に言えばローカルにメールがダウンロードされるタイプ。ＩＭＡＰはサーバ側にメールデータが有るので、複数のパソコンで共有するのに便利ということ。ただしメールデータがサーバ側に残るのでサーバの容量を圧迫するとともにメールを読むたびに通信が発生するということだ。

「今の容量だとちょっと心もとないかな」

　むこうだとテラバイトクラスのＨＤＤがとても安価に買えるが、こっちはまだギガバイトクラスだ。

　全員分のメールを保存するにはちょっと心もとないか？

　通信速度もそんなに早いわけでもないし。

　とするとＰＯＰ３しか今の所選択肢はない。

　さて、インターネットであればこのサーバのＩＰアドレスやメールドメインとポートなんかを指定して送受信するわけだが、今の僕にインターネットのようなデータ転送システムが組めるであろうか？

　簡単な原理は知っているとはいえ、やるべきことは多い。

　とても僕一人でどうにかできるとは思えない。

　しかも現在はすべてが無線での接続だ。

　ひとつのアクセスポイント(ＡＰ)とぶら下がっている端末間はひとつのチャンネルを使えばいいとしてＡＰとＡＰ間のアクセスにはもう一つチャンネルが必要になるだろう。

　二つのチャンネルを同時にアクセスするということは負荷が二倍になるということでも有る。

　リング状にＡＰをつなぐなら、さらにもう一個チャンネルが必要になるし、格子状なら四チャンネルだ。

　下手をすれば転送だけでチャンネルと処理能力を使い果たしかねない。

　四チャンネルが同時に送信を始めたら、データ量四倍だからね。

　処理能力を一チャンネルあたり二〇～三〇%程度になるよう調整した場合、通信だけで処理能力が飽和する。

「詰んだ」

　ネットワーク対応二日目にして詰みかよ。

　まあ、これまでも乗り越えてきたんだ。

　なんとかなるさ。

　詰んだ時は昔に立ち返ろう。

　そう。

　昔はインターネットなんかなかったし、パソコン通信とかもっと簡単な仕組みでネットワークが作られていた。

　インターネットが作られるまで、ネットワークと言えばホストを中心とし端末がぶら下がるようにして繋がれていた。

　しかしこの場合拠点のホストが壊れたり破壊されると全部ダメになるということで、サーバを分散し一つが壊れても全部がだめにならない仕組み、インターネットが作られた。

　元々が軍事技術なので、きちんと実装しようと思えばたくさんの規約があってうんざりすること請け合いだ。

　だがその前のパソコン通信ならどうであろうか？

　パソコン通信とは電話回線などでホスト局につなぎそこで掲示板を見たり、チャットやメールしたり、ファイルのアップロード・ダウンロードなんかできたりした。

　いわゆる草の根ネットなどという、個人が運営するホスト局がそれこそ無数にあり、大手とはまた違ったコミュニティが作られていたものだ。

　個人局なので回線が一本というところも少なくなく、多いところだと個人で数一〇本とかの回線を持つ大手の個人局も存在した。

　ホストに使っているのもそのへんのパソコンで、ＰＣ９８００シリーズなんかがＤＯＳベースで使われていたはずだ。

　つまり今の精霊コンピュータでもパソコン通信くらいの機能なら持たせられるはずである。

「ホストはひとつ、それに端末を全部つなぐパソコン通信形態。これならパケットの転送機能とか不要だ」

　ホストにはチャット機能、メール機能、掲示板機能、ファイルのアップロード・ダウンロード機能があればいいだろう。

　掲示板はグループウェアの原始的形態と言えないわけではないし、ファイルアップロードとダウンロードができればファイル共有もできる。

　別に仮想ドライブとして開ける必要もない。

　まあ、通信距離の問題はあるが、今はそれほど離れた場所からアクセスすることもないだろうし。

「なんかできそうな気がしてきた」

　やはり昔の人は偉大だった。

　有るものを工夫して使っていた。

　今は確かに便利になったけど、今はそれを使うだけで創意工夫というものがなくなった気がする。

　昔は必要があれば自分でツールを作ってより使いやすくしたものだが、今は便利なアプリを探してきて、気に入らなけば捨てる。

　年寄りの郷愁かもしれないが、昔は不便でもその不便さを楽しんでいた気がする。

　引退間際のころだと、フリーソフトをダウンロードしてきても、こいつつかえねーとかいってすぐ削除。次を探してくる。何か自分で作るとか工夫するよりそのほうが早かったしね。

　しかし今は本当になにもない。

　自分で作らないと何も手にはできないのだ。

「よし。まずはメールサーバを形にしよう」

　メールサーバにはデータを受け取り、保存し、宛先ごと配信する機能が必要だ。

　また、メールが来たら知らせてくれる機能もほしい。

　昔はそんな機能はなかったが、流石にアプリを起動するまでメールが来たかどうかわからないのはいかがなものか。

　ただし既読表示、てめぇはだめだ。

　既読スルーなる言葉が生まれギクシャクしがちな今日このごろ。

　読まれたか不安になるのはわかるが、読まれたのに返事がない不安とどっちがマシかと言えば前者だろう。

　メールサーバは常駐しすぐに接続待ち状態になる。

　そこへ個人のパソコンが接続要求を出すと、セッションが確立する。

　これで送受信ができる状態となった。

　メールが来たら宛先ごとのメールボックスに保存し、各宛先とセッションがつながっていたらメールが来てるよ信号を発信。

　各パソコンでメールアプリが起動されたら、メールデータを送信し、メールボックスから削除する。

　まあ、流れはこんなものだろう。

　細かいことを言えばメーリングリストとか別名の定義とか色々やりたいことは有るが、まあ今は最低限の機能があればいい。

　あと考えないといけないのはセキュリティだ。

　メールは送った相手と送り先以外読めてしまってはいけない。

　サーバの管理者だって読めてはいけない。

　とすると、送信元の暗号キーで暗号化ー＞サーバで受信し送信元のキーで復号化ー＞送信先のキーで暗号化ー＞送信先へ送信ー＞送信先で復号化という手順になる。

　サーバ側の負担が結構多そうだ。

「あと、添付ファイルはどうするかな」

　今のインターネットメールは基本的にテキストベースのため、添付ファイルを送信する時はＢＡＳＥ６４とかでエンコードされる。

　ｈｔｍｌで画像データを埋め込む場合なんかにも使われていたりもする。

　昔のパソコン通信でもバイナリファイルの送受信ができないホストが結構あり、そんな場合ｉｓｈなどというアプリでバイナリファイルをテキストデータに変換してやり取りしたものだ。

「これも先人に習って、テキストデータに変換してくっつければいいか。くっつけるのはｈｔｍｌ準拠ということで」

　ｈｔｍｌはテキストベースでいろいろな属性をテキスト中に埋め込めるので便利だ。

　今のエディタではＧＵＩで編集はできないが表示はできるので、メーラにもこのエディタを組み込めば装飾されたメールだって送れる。

　まあ、バイナリをテキストに変換するためデータが増大してしまうという欠点は有るが、エディタで見たり変更できたりすると簡単に修正ができるからテキストのどこに埋め込むとか簡単に変更できるので利便性は高い。

　メールや掲示板で使えるデータは当面テキストベースでいいだろう。

　バイナリデータがやり取りできないわけではないがテキストと別扱いにする場合、データフォーマットを決めたりとめんどくさい。

　それなら既存のものを使えば考えることが少なくて済む。

　先人の知恵を生かしてこその知識チートだからね。

　自分で考えたらもはやそれはチートではない。

「さて、メールサーバを作っていきますか」

　今の所パソコンとパソコンは一対多でつなぐパソコン通信形式なのでＴＣＰ／ＩＰといったインターネットの仕組みは必要ない。

　あれはＩＰによって送受信先を決めたり、受信データを各アプリに振り分けたりする機能だからね。

　基本シングルプロセスの今、メールサーバには将来的に掲示板機能やチャット機能が追加されていく。

　データ転送機能も各アプリへの振り分けも必要ないので、ネットワーク層やトランスポート層なんて言われている部分はまるっと省略できる。

「あれ？　ということはネットワーク部分はすでに終了してた？」

　お前はもう死んでいるを食らった気分だ。

　あれだけいろいろ考えてたのに、インターネット部分をまるっと削除してパソコン通信方式で行くと決めた途端やることがなくなった。

　メールサーバはすでにアプリの領分だ。

　いや、ＳＳＩＤの収集とセッション確立の部分がまだだったが、ホストが一台しかないのであればそんなものは必要ない。

　チャンネルひとつのＳＳＩＤ決め打ちでいい。

　いや、ＳＳＩＤどころか固有ＩＤがあればすでに通信はできる。

　接続時の暗号化も不要だ。

　何しろ盗聴できる機器がこの世界に存在していないからね。

　サーバ内のデータが暗号化されていないのは不安だけど、今でも企業メールとか管理者が確認できるようになっているところもあるし、不正使用があれば確認することが有ると通知しとけばいいよね。

　存在していない危機を心配しても始まらない。

　必要になりそうな時に考えよう。

「資料は将来のために残しておけばいいか」

　まあ、記憶は記録しておかないとそのうち消えていっちゃうからね。

　無駄じゃない。

　ちょっと遠回りした感はあるけど。

　今後小規模なインターネットのような物が必要になるかもしれないしね。

　例えば王都とつなぐような場合、長距離通信用の別のホストを用意したい。

　電離層の性質が元の世界の地球と同じかどうかわからないけど、むこうの地球なら短波を利用すれば電離層で反射して出力が十分あれば地球の裏側まで届いた。

　今はラジオ自体廃れてきているが、昔はテレビと並ぶ情報ツールであった。

　インターネットなんかなかったしね。

　ＡＭラジオだって夜ならかなり遠くまで届いたし、短波だと海外の日本語放送なんかたくさん聞けた。

　昔海外放送を聞いてベリカードをもらうＢＣＬなんかも流行ったなぁ。

　親父に無理言って短波放送を聞けるラジオを買ってもらったっけ。

　実際に僕もベリカードを何枚かもらったことが有る。

　王都なんかとつないでメールをやり取りする場合、おそらくこの短波帯を利用することになるが、下手をすると地球の裏側まで届きかねない。

　ユーザーが少ないうちは問題ないだろうが、ユーザーが多くなると競合が増えて使い物にならなくなる可能性がある。

　なので、近距離で使う場合は八〇〇メガヘルツ帯とかｗｉｆｉなんかでも使っている二・四ギガヘルツや五ギガヘルツの高周波帯を好きに使ってもらい、長距離通信は許可されたホストだけが短波帯を使って近距離用のＡＰとつなぐ。

　限定された範囲であればデータ転送もそんなに複雑にならないだろうし、帯域的にも負担が少ない。

　王都や派閥領地とメールやチャットができればまあ、十分だろう。

　長距離伝送サーバとメールサーバをつなぐくらいであればそんなに難しくはないはずだ。

　長距離伝送サーバはメールサーバに転送するだけで済むわけだし。

　インターネットのような複雑な仕組みはいらない。

「暗号化はめんどいからとりあえず平文のやり取りだけできるようにするかな」

　まずはシンプルに。

　暗号化は他領とかとつなぐときまでに作ればいい。

　それまでネットワークが使えるのはここだけだし。

　データの中身も身内だけだから暗号化はそのうちでも問題はないはずだ。

　本当に秘密の通信なら手紙でもいいわけだし。

「よし、だいぶスッキリしてきた」

　これまで難しく考えていた分、面倒くささがだいぶ減った。

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

　いつものセリフをつぶやきながら、僕はパソコンに向かった。

---

　今短波ラジオを聞いている人ってどのくらいいるんでしょうね。

　ちょっと調べてみたら、海外の日本語放送はだいぶ縮小されたようで、自分が昔聞いてた放送局でも日本語放送が終了していました。

　どうせなら遠い国のBCLカードがほしいと、エクアドルのをもらった記憶がありますが、ここもすでに放送は打ち切られたようです。

　まあ、放送されていたとしても今更ラジオを聞くことはないと思いますが。

　AMやFMすら聞いていませんからね。

　リスナーも少なくなっていますし、ラジオ放送はいつまで続けられるんでしょうか。