メールの仕組みって、RFCに規定されたものを読めば理解出来る..と言いつつ、実は
読んでもいないし、読んでも何を言われているのかさっぱり??..ってことですかね
その前に、ソケット通信とはなんぞや..とか、TCPとUDPの違いは？..などと、事前
知識があってあたりまえってことで、それも説明し出すと聞く方が長くて耐えられ
ない..ってことなんでしょうか？
まぁ、なんか書くだけ書いてみます。当たり前の話で恥ずかしいんですけどね。
メールが、送信側サーバから受信側サーバに送られ、メールボックスにおさまるまで
の話に限定してみます。
まず、受信側のサーバですが、常時25番ポートという入り口を開けて、いつでもメー
ルが受け付けられるように動いています。
送信側サーバは、その入り口に向けて、メールを送ればいいのですが、世界中のどの
メールサーバに送ったらいいのか？というのを、何で判断するか….これを勘違いし
ている人が多いんですね
「そりゃ、To:とかCc:とかに書いた宛先を見て送るんだろうよ..」
「それがどこに書いてあるかって？ ヘッダに書いてあるじゃんか！」
..って勘違いですね。
ヘッダにBccなんて書いていないのに、なぜ届くか？..と言えば、それが間違いである
のは理解いただけると思います。
実際には、エンベロープと呼ばれる「受信者のメールボックスには入らないけど、
サーバ上では付加されている情報」を見て判断しています。
メール1本のToやCcなどの中に、複数の会社の宛先を入れると、送信側のメールサーバ
は、複数の受信側メールサーバにメールを送ることになりますが、話を簡単にするため
に、そのうちの、１社に送られたものを対象に話を進めます。
受信側メールサーバに送られるメールには、同じ会社のAさん、Bさん、CさんにCcがつ
いていると思ってください。それでも、メールはまだ、その会社内の宛先を複数含む
１つのメールとして送られてきます。
このメールに、他社の社員のDさんにもCcがついていた場合であっても、受信側メール
サーバに到達した時点での、このメールの「エンベロープ」には、もうDさんの情報は
書かれていない状態になっています。送信側で、送り先の受信側サーバに配送を要求
することのないエンベロープ宛先を取り除くからです。
さて、受信側サーバに到着し始めたメール（メールは一瞬で届くわけではなく、メール
のサイズによっては結構な時間をかけて届きます）は、まずエンベロープやヘッダなど
から順に受け付けられ、メール本文や添付ファイルも全部受け取り、それを「メモリ上
ではなくハードディスクなどの不揮発記憶装置に書き込み終えてから」受け取り成功の
アンサを返すことになっています。
これ、厳密に言うと、ほとんどのソフトはそこまで本当に厳密には動いていなくて、
ライトバックキャッシュや、HDDに組み込まれているキャッシュに入りきり、OSに対す
る書き込み系システムコールが成功したら、成功としているんですけどね。
ハードウェアのキャッシュをライトスルーにして、かつ、OSでsyncモードでマウント
したファイルシステムに受信内容を書くのが、もっとも厳密なわけですけど、それを
やるとディスクの物理速度に足を引っ張られて、大幅にパフォーマンスダウンしてし
まうので、そこまではしないのが普通です。
良いRAIDはキャッシュをSRAMバッテリバックアップで持たせ、さらにサーバもUPSで守り、
停電ぐらいでは「書いたはずだが停電したら1ファイル無くなってる」なんてことを防ぐ
ようにするからです。
あ….話が脱線しました。
一般には、受信し終えたときにディスクに書き込まれるファイルは、メールボックスに
直接入るのではなく、一時ファイルとして記録されます。
大きなメールでは、受信完了までに長い時間がかかるため、別のサーバから、別のメー
ルが次々届くことになります。そういうことに対応できるように、メールサーバは、
マルチスレッドやマルチプロセスで並列処理を行い、1つのメールの受信中にも、別の
スレッドが25番ポートへの着信を待ち受け、次々並列処理で受信が行えるようになって
います。
とはいえ、サーバも無限大の能力があるわけではないですから、並列で受信できる数の
上限は定められているか、設定による可変の上限値が与えられています。
これを超えた並列度でメールが送りつけられてくると、「どのスレッドも25番ポートで
待ち受けていない」状態が生じます。すると、その状態で新たに接続しに来た別のサー
バにとっては、接続を受け付けてもらえない状態が生じるようになります。
….あぁ….どんどん脱線する….
そういうのを、ポートによる死活監視を行うタイプのクラスタリングソフトなんかで、
フェイルオーバー型クラスタにしちゃってると、生きているのにフェイルオーバーが
起こる..ってことになるんですが….濃い話なので先に進みます。
さてさて、とりあえずの受信が済み、一時ファイルになったメールは、宛先となる人
全てのメールボックスに格納されなければなりません。
メールボックスへの配送作業は、それ専用の別スレッドで行うソフトが多く、一時ファ
イルを順番に処理できるように工夫されています。
メールボックスに配送する時点で、エンベロープ情報はもう不要になり、取り除かれて
しまいます。
メールボックスは、mbox形式と、maildir形式に大きく二分されますが、1ファイルに
どんどんメールを追記していくmbox形式は、いくらメール数が増えてもファイル数が
増えず、ディレクトリエントリの取得時間が増加することがない反面、壊れると全部の
内容を失う危険もあるわけですが、maildirでは、よっぽどため込まなければ、処理
速度云々の問題までは出ないので、こっちの方が良いかなぁ..と思われます。
で、ここでCGPの「おぉ！」という部分の一つがあるんです。
Ccとか、グループ配信とかで、1つの同じ内容のメールが、多くの人に配送される場合、
CGPでは、maildir形式において、1個しか実体のファイルを配送しないんですね。
他のメールボックスには、あたかも同じファイルがあるかのように見えるような、
「ハードリンク」を貼るだけなんです。で、読み出されてサーバ上から1人が削除を
するたびにハードリンクが減っていき、最後の1人が消した時点で、メールの本体が
実際に削除される….と。
これにより、グループなどの一斉配信系を多用する場合に、ディスク消費量をうんと
少なくできるし、実際に書き込まないのでディスクの物理的動作を軽減することで、
より高速な配送が出来るようになっているんです。
….あぁ….ホントはまだまだ書きたいのに….
これ以上書いても読み切れないでしょうからこの辺で終わりにします。
既に、ここまで読む人は少ないのかなぁ（笑）
バックアップ系の新商品がリリースできそうな形になってきたので、裏話を書きます。
もともとは、うちの会社のファイルサーバの体制不備が開発の発端です。
基本的に、担当者のPC内部に重要な情報が記録されるとき、ファイルサーバにも置くように徹底することで、PCがコケてもデータは残るというだけのファイルサーバだったのですが、これがイケてません。
ファイルサーバ自身のバックアップがないのは、貧乏な我が社でもあんまりの体制です。
退職者が出て、PCを初期化したりすると、データが2箇所に保存されていなくなってしまうし、そもそもどこにあるのかがわかりにくい。
で、退職者の扱ったデータの所在がわかりにくいのを解決するために生まれたのが、アイデクサーだったわけです。
ということで、今度の新商品は、ファイルサーバの丸ごとバックアップを以下に容易にするかという観点で作られました。ついでに、共有フォルダであれば、一般PCでもバックアップできちゃうようにと..
要は、我が社自身が便利に使いたいのが発端な訳ですね（汗）
さて、我が社では、開発・サポートを主業務とする関係上、グラフィック・音声・映像データなどの膨大な容量をファイルサーバに置くわけではありません。
このご時世のSATA-HDDは、1発で2TBもあるわけですから、なんとなれば、そこに全部収まるわけで、特段の開発をせずとも、バックアップそのものは出来ます。
しかし今後、ある程度の容量拡張が可能で、バックアップされた中身を容易に検索できるのであれば、それに超したことはありません。
そこで今回は、以下のようなものを開発したのです。
・Windowsファイル共有でアクセス可能な場所なら、どこでも、何台でも連続的にバックアップできる。
・バックアップ元PCにエージェント等を入れないでもバックアップできる
・Windowsファイル共有が可能であれば、バックアップ元のOSは問わない
・Webユーザインターフェースで、バックアップ元の登録やバックアップ時刻設定が簡単にできる
・あとからディスクを追加すれば、LVMでどんどん容量追加してバックアップ先の内蔵ディスクを増やせる
※今は1発で最大2TBだけど、将来もっと大きなディスクが出てくれば、もっと大きなバックアップが出来る
・LVMを使ったディスク拡張を、ボタン一発で自動実行するインターフェース搭載
・アイデクサーのエンジンを流用し、バックアップ内の検索をかんたんにできる
・バックアップが行われるたびに、自動的に検索インデックスを再作成する
・検索は、アイデクサー同様、ファイル名・フォルダ名・全文検索対応
・検索時に、オフィス系を含むサムネイル表示・サムネイル拡大が出来る
・アイデクサー同様にEXIF検索やPDF検索も搭載
・基本的にモニタ／キーボード無しで運用できるだけのWebインターフェースの充実
・モニタ無し時の利便性の一環で、Beep音で状況に即したメロディーを流す
・バックアップの終了や使用容量の通知をメールで出す
・もちろん、エラー系の通知も日本語で詳しいメールが出る
・通知は、エラー・警告・一般通知のレベルに分けられ、それぞれ通知先アドレスを変えられる
….どうです。てんこ盛りでしょ（笑）
バックアップ元登録時に、そのバックアップ元をマウントする際に使うユーザ名／パスワードを個別登録するんですけど、登録実行ボタンを押すと、実際にマウント可能かどうかを調査してから登録を受け付ける仕組みになっています。
これを作っているときに思ったのですけど、Windowsファイル共有を対象にするなら、nmblookupでアクセス可能な全マシンをリストして、片っ端からアクセスし、ユーザ名をAdministrator固定で、パスワードの総当たりハックを仕掛け、当たったら勝手にバックアップ元に登録しちゃう仕組みにしたら、そこらのPCの共有部分をみーんな勝手にバックアップできるかも..（汗）..とも思ったのですが、犯罪っぽい臭いがするのでやめました(^^;;
本当はMacのAFPを同様に扱えると、さらに良いなぁ..って思いもあるんですけど、まだ、LinuxからAFPで共有ボリュームをマウントしたりクライアントアクセスしたりする手法の確実性が疑問です。
まぁ、mount -t cifs並に便利なmount -t afp の登場とか、smbclientのように使えるafpclientの出現とかは期待できそうにないけど、暇を見て以下を試してみるのも良いかな..とも思っています。
http://alexthepuffin.googlepages.com/home
http://sourceforge.net/projects/afpfs-ng/
FedoraCore8用みたいですが、おそらく、実際に使うときは、CIFSでバックアップした内容との混在を避けなければならないのは間違いなさそうだし、これを今度はafpdでnetatalkから公開したときに、Mac側でまともに見えるものになるのか..と言う点が最低限クリアされなければいけないと考えています。
混在を避けなければならない理由を細かく書けばきりがないのですけど、Macが、UTF-8の扱いを他と違えていることがもっとも気に入らない点ですね。
MacのUTF-8って、内部的には全角ひらがなの「が」を、「か」＋「゛を示すコード」で示し、DVDなんかみたいな外部のメディアの場合は「が」のままで許すとか、よくわからない仕組みになっているんですよ。
他の仕事で、Macが作ったファイルでは相当苦労させられているので、やるときは経験を踏まえてしっかり作らなきゃ行けないと思うし、Mac対応は仮に出来たとしてもずっと先かなぁ(^^;;
これまでうちのエンドユーザさんはLinuxが中心、WindowsやMacが少々って感じだったんだけど、Solarisユーザも加わって、そっち方向のスキルも蓄積され始めました。
基本的には、x86版のOpen Solarisでだいたいのことはわかっていたんだけど、どうしたってSPARCプロセッサのマシンにも馴染んでおきたいのは人情です。
で、私物で買っちゃいました（＾＾；； Sun SPARCの中古サーバ＼(^O^)／
なんと格安4980円（爆）
で、届いてみれば、付いているはずの内蔵CD-ROMドライブは入っていないし、コネクタが特殊だから他のマシンのIDE CD-ROMドライブは繋がらないし….まぁ、幸いSCSIインターフェースがあったから、古～いSCSIーCDROMドライブをつないで、なんとかSolaris 10をインストールして使えるようになりました。
使えるようになりゃ、なにかプログラムを作ってみたいのも人情ってもんで、Linuxで作っていたプラグインの第二弾を早速移植してみました。
普通に動くよぉ！！ （結構感動）
gccを入れてもパスは通っていないし、makeもそうだし、癖はあるけど全然OKです。
MacのPowerPCにも移植して、こっちもOK！
あとはWindowsとか、x86版Solarisなんかも行けそうなんだけど、ネックが一つ！
うちの会社には、IntelのMacがないんだなぁ(^^;;
これも私物で買っちゃうことになるんだろうか（汗）
社内のCGPに新開発のプラグインを入れて速度試験をしていてつくづく思った。
やっぱ、Cっしょ！
2296回の暗号化ヘッダ追加処理で、CPU使用時間の総計は0.20秒！
1回当たり、0.087ミリ秒だもんね。
100万分の87秒って無意味に短い処理時間だけど、Perlとかじゃこうはいかないよなぁ
そういえば、バス運行表をPerl言語でウェブ整形表示するプログラムを書いているとき、バスの運行表をウェブで公開している会社はどのくらいあるんだろうと調べていると、すごく面白いサイトを見つけてしまった。いわゆるバスマニアというかバスおたくが公開しているサイトである。何がすごいって、「○○観光の車番□□番のバスは平成？年頃廃車になった」とか、「□□にある車庫は平成？年頃廃止された」とか、やたらと細かい。しかも各バス会社が所有しているバスの写真は当たり前、車両ナンバーまで掲載されているという凝りようである。それゆえ廃車してナンバーの取れたバスの外観だけをみて「これは栃木２２う○□×△である」とか判別が付いてしまう。
しかもそのバスおたくはどうも栃木県人であるらしい。というのは栃木県のバス事情に特に詳しいからである。関東のバス会社のみならず、東北のバス会社まで一部掲載されている。一体その取材力はどうやって発揮されるのだろうかと疑問に思ってしまった。
鉄道ヲタクはてっちゃん、バスおたくは何ていうのだろうか？その方のハンドルネームは「サルビア」といい、下のＵＲＬがそのサイトである。
■栃木のバス資料館」
http://kitabus.net/
前々から機会があればやろうと思っていたけど、雑務に流されてできなかった、CGPのプラグイン作り！
やってみるとこれが結構楽しい。
基本的に、CGPからたたき起こされて動きっぱなしになるプロセスが、ずーっと標準入力を待っている..というスタンスで作るんです。
親プロセスたるCGPから、プラグインの標準入力に、そのコマンドのID、コマンド名、パラメータを受け取り、それに関する適切な応答を、標準出力に返す..という作りにするだけで動きます。
そのコマンドから、パラメータとしてキューのファイル名を受け取れるので、キューのファイル内を調べて何らかの処理をすれば、結構好きなことが出来ます。
受信後のメールのファイルになっちゃうと失われてしまうエンベロープの中身が、キューのファイルには入っているので、それを調べて出来るようなことを、独自に組み込めるわけですね。
今回は、エンベロープのTOアドレスを、全て読み出して、それを結合した後で、暗号化を行い、暗号化した全てのTOを、独自ヘッダに埋め込むプラグインを作りました。
どういう意味があるのかって？
エンベロープのTOを見れば、BCCの宛先も読めるわけですよ。
最近じゃ、内部統制がどうとかで、メールをぜーんぶアーカイブしてくれってお客さんも多くて、ぜーんぶアーカイブしたものがどこに送られたかも、全て知りたいって要求があるんですわ
かといって、BCCの中身を読めるようにして付けちゃったらBCCの意味がなくなっちゃうから、暗号化して読めなくして、キーを知っている管理者さんだけが読めるようにするわけ
でもね、お客さんの中には、日量20万通ぐらいのメールを送受信しているところもあるし、暗号化も含め、やっぱ超高速じゃなきゃ嫌でしょ！ ….ってことで、C言語ですっかすか速く動く奴に仕上げました。
CGPのフリーのプラグインって、Perlの奴が多いけど、やっぱCだよねぇ～！！
で、これを国内初のプラグイン製品として、売り出そうって話もあるんで、どう紹介しようか悩んでるんだよね
CGPのアーカイブソリューションは、仕組みを熟知していれば、お手軽にいろいろ仕上げられるんだけど、それをどうやってわかりやすく説明しようかってね
商品名だってわかりやすくしたいし！
前に「Open BCC」なんて冗談で言ったんだけど、どうなるのかなぁ
作った本人としては、Linux版のデコーダーソフトやWebデコーダーページも含めて格安提供して、たくさんの人に使ってみてもらいたいんだよね
開発開始当初に社内向けに約束した、11月中β版リリース、12月製品版リリースというスケジュールは何とか守れました。
毎週金曜日の23時40分に、社内の検索対象ディレクトリにある55万ファイルのインデックス更新を動かしているんだけど、翌朝4時前には毎週終わっているし、55万ファイルの巡回時間で4時間20分ってのは、毎日巡回に耐えると言っていいのかなぁ？
でも、これ、うちの会社はファイルサーバもAidexerもギガビット接続だし、100Mbpsでできあがっている所じゃ辛いかもねぇ
まぁ、Aidexerの能率があんまり上がると、ファイルサーバの応答速度を食ってでも全力で巡回しちゃうから、日中に巡回バリバリって状況は避けたいし、やっぱり毎週末の実行がおすすめですね！
そうそう、最初の1回目の巡回は結構時間かかるから、うちぐらいの規模だと、全域サムネイル生成・全文検索インデックス作成が終わるまで、1週間近い巡回が必要になるでしょう。その間も、巡回を終えたところから順に検索は出来るけど、巡回中はやっぱりそれなりに検索は重くなります。
nice値を設定し直して、巡回側プログラムは低いプライオリティで動いてはいるけど、どうしてもディスクI/Oの多さは避けられないし、やっぱ、導入後の最初の巡回を終えてからが、Aidexerの本領発揮って感じでしょうかね！
当初はねぇ、これって社長の個人PCの中がぐっちゃぐちゃで、何をどこに置いたかわかんなくなったから、それを探せる奴作ってよ！って話から始まったんだよね
でも、それじゃGoogleDesktopと同じだし、同じぐっちゃぐちゃな状況の社内ファイルサーバを検索できる方向で、でも、個人PCの中も検索できるようにね！って話になったんだ
だからWindowsPCに入るWindows版で作り始めて、それが十分動く程度になってから、出荷にかかる周辺費用の話が出たら、「やっぱり安く出荷できるLinuxでいこう！」って話になってさ(^^;;
相当部分がLinux対応で作り直し。しかもFedoraCore9で始めてから、途中からCentOS5に切り替えてドタバタ（汗）
で、社内ファイルサーバの検索が一通り出来るようになったら、社外から営業デモ用に直接検索画面が使えないか？って話になって、ゲートウェイ側の設定変更して別ポートから社内Aidexerのポート80へのポートフォワードをして、見えるようにしてみたの
そしたらまたこれが社長のお気に入りになっちゃって、検索できたらファイルが取り出したいよね！って、そりゃそうだよね
かといってSAMBAのGlobal公開なんてあり得ないから、見つけたファイルをメールに添付して送れちゃう仕組みを、オプションとして作っちゃったんだな（＾＾）
@dragon-networks.com宛にしか送れない仕組みにしたし、ある意味セキュア、ある意味「いいのか？これ？」って感じだなぁ
つまんないルールで縛られず、社員が出先でより便利に活動できるならどんどんやれ！って会社にとっちゃ、相当使えるツールだとは思うけどなぁ…..
使い方よくわかっていないけど、こんな感じで良いのかな？
なんか、漢字変換うまくいかないから、秀丸で書いて貼り付けてるけど(^^;;
AIdexerのLinux版が、やっと人様に見て貰えるレベルになりました(^^)
社長の一声でWindows版オンリーってことで始まり、途中でコストの話でLinux版
開発に転向、それをFedora9で始めちゃったのが運のつきで、やっているうちに
あれこれモジュールの入れ替えの必要性にぶち当たり、果てはglibcまで入れ替え
て、rpm500個を以上のアップデートする羽目に….
結局アプライアンス機としての供給の容易さと安定度の両立のために、CentOS5.2
での構成に作り直し(^^;;
だいぶその辺で時間を食っちゃいました(笑)
PHPの5.2.0以上依存の部分もあったから、素のCentOSよりはだいぶ入れ替えが起
こったけど、それでもFedoraCore9ベースでやるよりは、うんと少ないモジュール
入れ替えで済みました。
早く初号機の出荷をして、ユーザの声を聞きたいなぁ