Yukiharu YABUKI の tDiary

_ arpが絡むとはいえ、UDPデータグラムが消失するからくりは、なかなかぱっと思いつかないよね。

Windowsでの話。[INFO] MTU より大きな UDP データグラムが通知なしに破棄される

Windows以外のOSでの実装はどうなんでしょうか。

_ ICMP source quench

ICMPの記事(http://www.atmarkit.co.jp/fnetwork/netcom/netcom01/netcom01.html)は2001年であるので書いていないが、「source quench:軋轢発生による転送抑制指示」は、2004年12月と記載されている(http://www.watersprings.org/pub/id/draft-gont-tcpm-icmp-attacks-03.txt)に、簡単にスループットを落とす手段を提供しているとして、注意が喚起されている。

元々は、ICMP source quench は、「そんなに、いっぱい送られてもこまっちゃうよ」というお返事をデータの送信元に送り返すことで、簡単なフロー制御を行っていた。TCPの場合なら、初期のスロースタートの状態に戻すし、UDPの場合なら送信レートを落としていた。ただし、これらの挙動は必須ではなかった。

しかし、上記の仕組みを悪用して、スループットを劇的に下げる攻撃が出たため、RHは(http://www.jp.redhat.com/support/errata/RHSA/RHSA-2005-017J.html)を出したし、CISCOは、(http://www.cisco.com/JP/support/public/ht/security/102/1021599/cisco-sa-20050412-icmp-j.shtml)の対策を打ち出した。

上記のインターネットドラフトにより、RHとCISCOは対策をした。でも、Linuxカーネルは、/proc/配下の設定で、source quench を出すのを辞めてしまったのかの理由は、私はまだ見つけていない。

_ shaper と ICMP source quench

ということで、traffic shaper が流量を絞った場合に、送信したクライアントに関して ICMP source quench の元々の意義を考えると、shap してパケット落ちが発生したときに、送信量を下げろというために使うのは、いまとのなっては、どのぐらい意味のあることなのだろうか? と思う。上記のドラフトがでてからはICMP source quench を無視する実装がどのぐらい増えているかも気になる。

_ tc qdisc

読み方は、(http://www.linux.or.jp/JF/JFdocs/Adv-Routing-HOWTO/lartc.qdisc.classless.html)のpfifo_fastの部分を参照せよ。TOSの値の組み合わせが「0」から「F」まで表示されていることに着目注意せよ。

yelona:~# tc qdisc
qdisc pfifo_fast 0: dev eth0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wmaster0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev wlan0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp0 root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

_ http.elのタイムアウト値を伸ばしてみた。

netfort.gr.jpの、loadavg が 9とか11の数字になっており、tdiary.el が tdiary からの HTML 取得に 10 では失敗するので http.el の中をみて、タイムアウト値を10秒から30秒へ変えて様子を見ることにした。

大量のspamがfmlに襲いかかっていて、loadavgが上がっていた模様。bad receipt 原因となるメールアドレスを登録してもらい、loadavgが平和な数値になった。ということで、http.elのタイムアウト値を小さくして快適になった。

_ JFプロジェクトの web 掲示板

MLは、はやらないためか。sourceforge.jpにweb掲示板ができたようですね。(http://sourceforge.jp/forum/forum.php?forum_id=15237)

_ linux-source-2.6.(18|27)/net/sched/sched/sch_tbf.(c|h)

tcのqdisc tbfは、このあたりと連携しているに違いない。

yelona:/usr/src/linux-source-2.6.27/net/sched# wc sch_tbf.c
  493  1519 11324 sch_tbf.c
yabuki@Ernalda:~/src/linux-source-2.6.18/net/sched$ wc sch_tbf.c
  543  1605 12308 sch_tbf.c

カーネルバージョン/net/sched ディレクトリにある、Kconfigをみて、よりそう思った。

sch_api.c および sch_generic.c は眺めておかないと、見落としが出るかも。

_ HandBrake日本語版

(http://sourceforge.jp/projects/handbrake-jp)どんなプロジェクトかというと、概要の引用を下記にしておきます。

オープンソースかつマルチプラットフォームの動画エンコーディングツール「HandBrake」（http://handbrake.fr/ ）日本語版を作成・提供するプロジェクトです。
HandBrakeは、DVDやDVDのISOイメージをメディアプレーヤーやPS3/Xbox360/PSPなどのゲーム機などで再生できる形式に変換できるエンコードツールです。オープンソースで開発されており、WindowsやLinux、Mac OS Xで動作します。
オリジナルのHandBrakeは、複数の有志によって開発されていますが、海外の開発者が開発をしているため、いまのところ日本語化がされていません（日本語環境で問題なく動作します）。そこで、本プロジェクトではHandBrakeの日本語化と、日本語化されたアプリケーションの配布を行う予定です。なお、本プロジェクトではWindows版/Mac OS X版/Linux版すべての日本語化を行う予定です。

PCをもっていない層に、画像などを通じてアクセスする手段として利用できそうです。

_ pthread:signal, barrier

pthread の signal の扱いと、barrier の扱いについての記事です。(http://codezine.jp/article/detail/1973) barrier とは

バリアは、ある特定の処理を行う時に全スレッドがその位置まで来ていることを保障するための機能です。

_ QoS:PSPacer バージョン 2.1.1

肝は、(http://www.gridmpi.org/pspacer-2.1/man.tc-psp.ja.html)に書いてある、「ペーシングアルゴリズム」だと思う。

既存のqdiscで実現している QoS との差をもっとwebで見せてくれるといいのだが。論文の方には、詳しく書いてあるかも知れない。

_ 会社の本店移動に関して

法務局だけでなく、税務署にも届けを出す必要あり。税務署も、旧の方で転出し、新の方で編入とのこと