日: 2020年5月9日

開発しているプログラムを別のプラットフォーム上でコンパイルして実行してテストしたい。少し変えてはテストしたいので、コンパイル結果は10秒程度で得られると良い。手持ちのツールだけでやりたい。

そう考えたのでとりあえず、変更したらプログラムをリモートのマシンにscpして、sshでコンパイルやテストのコマンドを送るという安直な方法にしました。今日びのOSはデフォでsshを装備しているので、追加でインストールするものはありません。

この手順を行う簡単なシェルスクリプトを書いただけで実現。変更分だけの再コンパイルであれば、差分が小さければ、コマンド打って10秒程度で結果が得られるのでほぼ満足しています。

気になったのは、プログラムをリモートに送り込むための時間です。ソースコード類のサイズはナマだと約10MB、tar して gzip して 2.5MB。scp だと状況によっては転送に数秒かかります。それだけでなく、これを何百回もやってると、サーバ側の従量ネットワーク課金が気になってしまいます。

それで思い出すのが昔懐かしい rsync です。ググってみると最近は通信に ssh を使うようになっていて、すごく健在のようでした。やはり原理的に良いものは生き残るのだな。よし、これで行こう。手元のマシンでも、リモートでも rsync とコマンドを打つと何か動くので、インストールされているようです。

どう使うのか？rsync -h とかするとどどっと出てくるので読む気にならない（（実は man rsyncの先頭だけ見ればサクッとわかることに後で気づく））。scp と同じノリで使えるとラッキーと思い、

% rsync ファイル リモートホスト:

としたら、そのまま動きました。 素晴らしいです。

性能的にはどうなんでしょう？超簡単なベンチマークをやってみました。

% openssl rand 10000000 > 10MB
% time rsync 10MB remote:
rsync 10MB remote:  0.46s user 0.37s system 6% cpu 12.435 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.08s system 7% cpu 1.833 total
% time rsync 10MB remote:
rsync 10MB remote:  0.06s user 0.07s system 7% cpu 1.804 total

リモートのファイルの cksum を確認しましたが、もちろん同一です。そしてこの例では、2回目以降は何もデータ内容に変更が無いので、何も送られていないようです。macOSの（とてもステキな）アクティビティモニターには、一発目の転送しか出てきません。

一方 scp では毎回データを転送してますので、毎回ニョキニョキと送信データグラフが伸びます。

% openssl rand 10000000 > 10MB
% time scp 10MB remote:
10MB     100% 9766KB 796.4KB/s   00:12    
scp 10MB remote:  0.18s user 0.20s system 2% cpu 13.473 total
% time scp 10MB remote:
10MB    100% 9766KB 893.0KB/s   00:10    
scp 10MB remote:  0.19s user 0.20s system 3% cpu 12.118 total
% time scp 10MB remote:
10MB       100% 9766KB 497.7KB/s   00:19    
scp 10MB remote:  0.19s user 0.19s system 1% cpu 20.791 total
…

このホスト関係、ネット環境だと、ssh 接続の確立に1.2秒かかる（この遅延、ログインする時に結構気になるんですが）ようなので、それよりは短縮できないですね。常設のトンネルw開通させておくしか無い。rsync自体の空作業は0.1秒未満の模様。

% echo a > a
% time scp a remote:
a                   100%    2     0.0KB/s   00:00
scp a remote:  0.01s user 0.01s system 2% cpu 1.217 total

% echo b > b    
% time rsync b remote:
rsync b remote:  0.01s user 0.02s system 2% cpu 1.283 total

考え所は、クラウド上のサーバのデータ（主に差分はログだけ）のバックアップも rsync でやるかどうかです。ファイル数が70万くらいあるので、変更されたファイルを効率的に知る方法が無いと、それを探索し回るのに結構な負荷がかかりそうです。まあ、変更した本人のサーバかOSが教えてやれればよいのでしょうけど。

とりあえずは、サーバ仮想マシンのディスクのスナップショットをとるほうが簡単だし全面的ですし、スナップショット保管料金は1日4円程度です。なので、あれはあれで良いかなという感じ。

クラウド上のドライブサービスも、rsync的な仕組みが入っていると良いですね。入ってるのかな？

2020-0509 sato@izmoh

---

先月 data URI scheme について書きましたが、今日はひょんな事から file URI scheme のお世話になりました。きっかけはこんな事でした。

「場所がわかっているファイルを簡単に開きたいのだが？」

そこで思い出したのが file URL [RFC8089]です。さっそく、ブラウザにファイルの場所（パス名、つまり file URL）をコピペしたらパッと開きました。おっと！なんだこのサクサク感は！これこそ自分が求めていたものですよ。

ウェブブラウザで file URL を使えば、ローカルなフォルダやプレーンテキスト系のファイルを快適にブラウズできます。文字サイズの拡大縮小もブラウザ機能で簡単にできます。ウェブ系とシームレスに「ブックマーク」が管理できる点も素晴らしいです。

Mac の Finder にしろ Windows のエクスプローラにしろ、あのもっさり感にはうんざりしています。それに老眼のため「字が小さくて読めない！」「ポインターが合わせられない！」とか、「ダブルクリックができない！」とか（笑）。フォルダの中身をナマで見たいのに！とか。

ウェブブラウザは、HTTPをはじめとする上位レベルの、個別のアプリケーションプロトコルによる、明示的なリモートサーバへのアクセスを実現しています。一方で、昨今隆盛のネットワークドライブ（仮想ドライブ）に見られるように、下位レベルにおいて、リモートなファイルとローカルなファイルと区別せずにアクセスができる環境も整ってきました。

このように下位レイヤでリソースのビューが一元化が実現されていれば、お目当てのリソースに対して具体的にどのようなプロトコルでアクセスしているかを、エンドユーザが気にする必要ありません。それはまったくのところ、file:///path/name で十分なのです。

当社で開発中の技術の応用においては、リソースへのアクセスを、こちらのエンドポイント（ユーザアプリ）からあちらのエンドポイント（リソース）に至るどこかの地点で捕捉し介入する必要があります。その地点としては、個別アプシケーションプロトコルのどこかのノード、あるいはリモートファイルアクセスプロトコルだと思って来たのですが、いろんな意味でどうもイマイチです。

それで今日思ったのは「やっぱブラウザでいいんじゃね？」ということです。ブラウザでやる、というのは最初に考えることではありますが、ブラウザ以外のアプリからその恩恵にあずかれないというのが難点だと思っていました。ですが今思い出したのは「ブラウザをサーバにすればいいじゃん」ということです。ああ、昔はそんな事を考えていたなと。ブラウザはクライアントとしての機能は完備していますから、これを再び（いろんなプロコトルの）サーバとしてサービスすれば良いわけです。要するに結局、プロキシですね。

ここで考えを戻すと、たとえば sftp://xxx なんてのもブラウザで実装してあれば、プラットフォームでの実装を待つ必要もないわけです。

機能面以外で考えられる問題点はやはり、セキュリティ・プライバシーの問題です。なにしろ、今日のブラウザはプライバシーにアクセスするためのポータルです。これにサーバの口をつけて外部からアクセスされてしまうと、非常に危険だろうなとは感じます。だからそこはガッチリとガードするか、根本的に不能にするかですね。

逆に言えば、ファイル転送プロトコルのような下位のレベルでは、上位レイヤにおけるような意味構造に基づく細粒度のセキュリティ保護が難しいので、下のレイヤほどトンネルされると危険、制御不能とも言えます。

さてそれで、現状の主要ブラウザにおける file URL の実装はどうなっているかと見てみると、これがもう data URI よりもサブイ状況（笑）↓

20年前からまるで進歩していないですね。せめてフォルダ階層のパンクズリストぐらい出してよ、25年前のDeleGateですらやってたんですから、と思います。見た目は、まあしょうがないというか、いっそ清々しいです。Finderの代わりに使うには、アップロードの機能が無いのが困ります。

実装は、おそらく共通のライブラリをまんま使っているだけなのでしょう。見た目がほぼ全く同じです。FireFoxだけは、わずかな工夫をしています。またSafariは独自の丸投げ路線で、macOS上ではFinderを、Windows上ではエクスプローラを呼んで済ませています。

見た目がこれだけしょぼいので、実装にも手が入れ易いのではないかと期待してしまいます。

2020-0509 sato@izmoh

---