EWFて、セキュリティのコンテキストでときどき話題に出されるけど、コマンド1つでコミットするだけで、悪い更新をシステムボリュームに定着させることが簡単にできてしまうので、malwareにとっては攻撃回避は容易。したがって、これを(環境整備という範疇を越えて)セキュリティの道具として見るのは浅はかです。

こちらは、SATAのインターフェイス側で拾っているので、ブートセクターのウイルスなどは拾えるでしょうが、逆に、BitLockerなどの暗号化ソリューションが導入されているボリュームは検知できないでしょうね。

それは知らなかった。参考になりました。ありがとうございました。

これって、まだしばらくセキュリティ更新プログラムが提供される Windows XP Embedded (ATM やコンビニの端末などの組込み用途に提供されている特別エディション)のためにウイルス対策メーカーが Windows XP (Embedded)のサポートを続けると言っているだけですよね。

Windows XP にセキュリティ更新プログラムが提供されない以上は、いくらウイルス対策ソフトをアップデートしたところで Windows XP そのものに脆弱性は残ることになる。

ウイルス対策ソフトだけでは、防ぐことができない攻撃やウイルスなども出てくる可能性がある以上は Windows XP は4月以降は使ってはならないものであり、この認識がかわったわけではない。

心を落ち着かせるためにElbrthと書くようなもんか。

そうね。ごめん。まちがえた。

中部アカデミックネットワークが権利能力なき社団(みなし法人)であって、氏に授権が行なわれている(「代表者は〜にあたって、法的措置を催行できる」と会則に書いてあるか、又は、訴訟を行なう旨を議決している)ならば、原告としての適格性を有することになる。ちなみに、弁護士か、権利能力なき社団の代表者しか原告代理人にしかになれません。氏が代表者になるつもりであろうか。

ちなみに、「後がないから」ってのはよくわからない。このような結果になったのは、相手が答弁書で棄却を求めただけだと思うのだけど、普通にかんがえれば、社団への請求であったのなら、棄却されるのは自明であるので、単なる金の無駄でしかない。私には「後がないから」という戦略ではなく、単なる道楽の裁判にしか見えない。

COBOLみたいな初等的な（しかも理解が易しい）言語は、いざとなったら誰でもできるんじゃないの？C++やJavaなんかと比べると言語仕様は圧倒的にコンパクトなはずだよね。一時的な上昇はあったとしても、そんなに進んで修練するほどの言語だとは思わないなあ。

TCPは車のトラフィックと同じ。TCPでは、

1. 事故が起こったら速度を下げる(事故が起こらないならどんどん速度をあげる)
2. 目の前の人の速度が遅くなったら速度を下げる(目の前の人の速度が遅くならないならどんどん速度をあげる)

のどちらか、または、併用したものを採用する。

インターネット標準は、1ですが、条件によって2を標準とするOSもあり。

1では、道の太さを無視して、事故が起こるまでは速度をどんどんあげていって、事故が起こると、通信速度を下げよう、というような処理を行っています。（これは、TCPの場合は事故が起こった場合のコストが比較的小さいからできる技です。）

NextTCPを考えるといっても、所詮、狭い道で早い速度を出しすぎると事故が起こるのは明確だし、事故が起こると渋滞が起こって余計に目標到達が遅くなってしまうから、ある程度ゆっくりな速度で走らざるをえないというのは自然の摂理なわけです。速度の上げ方を巧妙に選んだHighSpeed TCPというものもありますが、制御だけでがんばっても限界はあります。

TCPのエンドは、TCP単体では回線の太さを事前に知ることができないので、適切な速度を選びづらいという特性もあります。元記事のように、事前に回線速度がわかっていれば、1, 2 をベースとし、その増加量や再送手順を工夫した高い通信効率を持つ通信を実現することはできますが、それがすべてのインターネット通信に応用できるほどのものとはいえないでしょうね。

ゲーム理論を用いた解析結果(*1)では、「TCP（亜種を含む）で帯域を取り合った人が勝ち」というルールを設定して、皆で通信（ゲーム）を始めると、（高いトラフィックをかけすぎるとパケット棄却率があがって自分の帯域が確保できなくなるので）自分のトラフィックを適度に抑えつつ、現在のインターネット標準の負荷ではなく）ある程度高い負荷をかけるという結果に収束するということがわかっています。

さて、この状態下におけるネットワークの状態ですが、ルータのキューが常にいっぱいの状態であるので、帯域は最大限確保されますが、パケットの遅延が非常に大きくなるそうです。

すなわち、専用回線で他にトラフィックがない場合で、VoIPなどもない場合は、UDPでがんがん負荷をかけていただいて構わないわけですが、VoIPやらsshやらが流れている環境では正直厳しいでしょう。

で、一本まるまる専用線を（大容量データ転送だけに）占有できる環境は非常に稀でしょうから、そういう点を考慮して、どういうシステムが良いか、ということを考えると、ファイルサーバなら、DFSやらandrew fsやらの分散型ファイルシステムでレプリケーションを行う方式で、世界全国にサーバを持たせる形、そうでなければ、QoSで専用帯域を確保して通信を行うということが必要になります。

(*1)Tcp connection game: A study on the selfish behavior of tcp users

どうせブロックダイアグラムを書くのでオフバンド送信可能か
どうかなんて審査しようがないのではないかと思って調べて
みたらいろいろあるんですね～。