Diary of Sacred Fox - November 22, 2004

2004/11/22(1)

びばだめにんげんせいかつ

本日02:45に大学を出て03:00就寝, 11:00起床… 人間の最低ラインを軽く突破している聖狐ですこんにちわ… と, どっかの知らない人はこの単語をクエリにしてGoogleにでも訊いてくださいタライでごはんを作っている人みたいな挨拶をしてみたりするが, 上記のことは演出でも何でもない事実だから笑えないんですよね

そんなことはさておき, 今のところ聖狐はLinuxのネットワーク周りの部分を弄って卒論を書こうとしているのですが, なんだか想定しているのと結果が違うというか使い物にならない結果が出ているというか… これって『結局どうにもなりませんでした☆』とかいう超最悪の結論になりかねないなぁというぐらいに深刻な事態が発生していたわけですよ
で, 今朝コタツで暖をとりながらちょっと考えたところ, 原因はあの悪魔のノートパソコン, もといLaptop(K教官曰くあれはノートパソコンとは呼ばないんだそうな), 悪いのは某T社のへんてこなグラフィックチップだけではないのです情報理工ノートにあるというところに到達しまして… ま, しゃーないわなと言う結論に…, 此処まで達していなかったらこの研究を放り投げて今から分野探しをするという笑えない事態になったかもしれないと思うと背筋が寒くなるのですが…
問題はRealtime マシンから見て『出て行く』, 逆はIngressEgress PacketをEarly Deadline First レポート〆切と同じで, 全部のデッドラインが守れないと分かったら全体を遅らせてすべて駄目にするのではなく1つを犠牲にして被害を最小限に留めるというのが今回の研究ネタEDFスケジューリングをするために, デバイスのHW Queueの直前にQueueをここ, 造ると書くと語弊があるけど, 元からある(大して何もしない)Queueと入れ替えるというのが正確作ってやろうということをしているのですが, printkをカーネル内で呼び出してその出力をdmesgで拾って調べる, /var/log/messagesにも記録されるのだが, そのファイルがとんでもない容量に…デバッグメッセージを見る限りQueueには常に1パケットしかたまっていないという驚愕の事実が…
ところで, OS演習でFTPを作った時にBand Width Challengeをした人が少なからず居たと思いますが, その人は結果を思い出してください, NICの性能がちゃんと出ましたか? 出てませんでしたよね? なにしろNICのスピードよりもマシンのバスのスピードの方が小さいのですから… つまりQueueの手前が律速だったのでQueueには要素が溜まっていないと, 盲点でした
だからといって無線でやると研究室内の汎用マシンに実験中だけこっそりと立てているプログラム, その名もdevnullserver, 要はTCPパケットを読み捨ててくれりゃ良いので対向サーバを立てれるところがないしなぁ…, スイッチを噛ましてインタフェースに此処がポイントなので, 相手のスピードを落とすのは解決策にはならないのです(Congestionで道中で落ちて, Avoidanceとして送出頻度が落ちてもEnqueueが遅くなるだけで, デバイス周りの状況は何も変わらない, デバイスが律速になって欲しいのだから…)GbEを喋らせるのを止めさせるのも面倒そうだし… ということで今週入る予定の新しいマシンに開発環境を移して, ノートはデバイスを叩かせないとQueueは作れないので(loopbackだったらそもそも要らない), どうにかして外にパケットを出す必要があったり, 実はdevnullservを作る前はechoとかssh(Protocol Mismatchで落とされるので特に問題はない)を叩いていました対向サーバ & gaim & xmms専用機に成り下がるかもしれませぬ

Comments (0):

2004/11/22(4)

こんなものを作ってみる

1x1のgifファイル, よくアクセス解析とかに使われるやつ
これをUnix環境で作るのにこんな方法を使ってみる, →参考記事

$ echo 'static char *test[] = {"1 1 1 1", "  c #FFFFFF", " "};' > test.xpm
$ convert test.xpm test.gif

これをこんな感じのCGIで呼べばいい感じ

#!そのまま記述するのではなく, perlのパスに置き換えるという意味, 大抵/usr/local/bin, なければ/usr/bin/path/to/perl
# filename: アクセスするのに使われるURIの拡張子がgifじゃないと怪しいでしょ? これをCGIと認識させる方法は後述counter.gif
use 5;
use strict;
# ログ収集部分を此処に書く, 省略
HTTPレスポンスヘッダの改行はCRLFと決まっているのでテキストしか出力しない場合でも最初から明示的にbinmode + \r\nとすべき, そもそも画像の場合はこうしておかないとWindowsでは崩れるbinmode STDOUT;
ここに-s 'test.gif'の結果をContent-Lengthヘッダでかけるようになっていたら多分貴方は相当できる人なはずprint 'Content-Type: image/gif', "\r\n" こんな演算子を覚えている人ってどれだけ居るのでしょうか… 意外と便利x 2;
パスとかエラー処理とかそういった面倒なものは全部省略, 概略を示すのが目的だからopen FILE '<test.gif';
画像ファイルへのアクセスを書く場合は脊髄反射的にでもこのぐらい書いてあげないとね(テキストファイルでもbinmode + \r\nで書くのは賛否分かれるところがあると思いますが…)binmode FILE;
ちょっと悪辣なコードかも知れないが, これでFILEの中身を全てSTDOUTに吐き出せるprint $_ while <FILE>;
close FILE;
exit 0;

あとは適当な.htaccessとかhttpd.confhttpdのconfファイルで, SetHandler cgi-scriptを<files>セクションでセットしてあげれば準備完了, 外見上はちょっとだけアクセスに時間がかかる本当のgifファイルに見えること間違いなし, これを1x1画像ではなくてちゃっかりとページトップ画像なんかに仕掛けているともう邪悪としか言いようがないよね

因みにこれはCGIを使える環境があって, かつアクセス解析対象がレンタルサーバ(blog etc.)だったりするときに使えるテクニック, 何故こんな回りくどいことをしなければならないかというと, HTML内部の画像につくRefererはその画像を参照しているHTML本体で, これは解析対象外のアクセスをはじくのには使えてもそれ以上の役には立たないからJavaScriptでRefererも掻っ攫ったりとかするともう最強だけど, そんなことをしたらむしろこんなことをするのなら, スクリプトの拡張子をgifにするような真似はしない, それにJavaScriptは激しくブラウザ依存する, 単なるimgタグならlynxとかロボット以外なら何でもござれなのと比べると見劣り…解析しているとばれるので此処は我慢しよう
自分で書いたHTMLやCGI上ではこんな回りくどいことをする必要はないので, このサイトではこんなことはやっていませんよ

応用として引っ張り出すファイルをわざわざ書くまでのことじゃないけどこの場合はスクリプト名をdataなんてディレクトリに偽装して実際のデータはどこかHTTPアクセス出来ないところにおいておくという感じかな? くれぐれもエラーや攻撃対策はしっかりしましょう, data//etc/passwdとかやられてそのまま返すようではいけないPATH_INFOを使って決定するようにしておくと今度はダウンロードリクエスト数の解析器になったり, 負荷はかかるけどね
ちょっと使いそうだったので作ってみたけど結局使わなかったので邪悪メモとして公開