Open Tech Press | ルータファームウェアOpenWrtを拡張するX-Wrt
ユーザインターフェースを改良しましたよっと。作者コメントがツボ。
フォン・ジャパン、動画広告表示で公衆無線LANを15分間無料提供
フォン・ジャパン、動画広告表示で公衆無線LANを15分間無料提供：ITpro
単なる広告じゃなくて動画広告を利用するところがミソですな。
課金制サービスのAliensも始めるようだが、さて、どうなることやら。
L3アドホックネットワークのアドレス割り当て問題
半年頃前、アドホックネットワークにおいてアドレスの割り当てはどう行うのか、という疑問があり考えていた。
答えとしては、IPv6リンクローカルアドレスを使えば解決する、という結論に達した。
その答えを実証する記事があったので、紹介。
「Vistaは“IPv6に対応する”が決めごと」マイクロソフト及川氏
また、IPv6の利点として、ルータやDHCPがないケースにおけるアドホックネットワークの構築を挙げた。IPv4環境でルータやDHCPがない場合、Auto IDによる自動構成に63秒かかる一方、IPv6ではリンクローカルアドレスによって即座に自動構成するという。マイクロソフトではこのIPv6環境でのアドホックネットワークに注目し、アドホックネットワーク内でアプリケーションを共有する「People Near Me」機能も実装した。
及川氏は古川氏のブログでも触れられている通り、VistaへのIPv6等の対応のため尽力されたようで。
「People Near Me」という言葉すら知らなかった。Vistaは色々と面白そうじゃないデスカ。
あと、この及川氏、Vista出荷前にすでにマイクロソフトを辞めていて、現在はグーグルに居るらしい。YouTube – Google Developer Day Tokyo – 及川 卓也 -グーグル最新情報-にて彼がGoogle Gearsを紹介している、ということに繋がる。
DCCPの検証 (12)
LinuxのCCID実装の挙動について調査を行った。
無線LANアドホック1対1環境においてttcpで測定したところ、TCPでは２４Mbps、CCID2では20Mbps、CCID3では16Mbpsという結果が出た。TCPではMACのキュー捨てが発生しているがDCCPではCCID2、CCID3ともに発生しない。CCID2ではTCPの輻輳制御を持っているという話であり、TCPと同じくキュー捨てが発生するものと期待していたが、期待通りではなかった。
VLCの伝送においては、CCID2ではかなりのノイズが見られたのに対して、CCID3ではかなり改善された環境で見ることが出来た。キュー関連の挙動についてはttcpと同じく、捨てが見られない。VLCによる実際の映像データの伝送では、ttcpで測定できた16Mbps以上のスループットのデータを出力できている。よってttcpの測定パラメータが間違っていたということか。
ともかく、CCID3はかなり良い、期待通りの結果であり、MAC送信キューの溢れを防ぐ手としてシェーピングとして本環境については期待された仕事を行っていることが確認できた。まだVLC側のアプリケーションバッファの振る舞いがUDPに近いものなので、それをTCP的に動作するようにしてVLCにおけるDCCPの仕事は終わることだろう。
この結果を踏まえて次の論点は、本当にスループットが落ちている場合に、最後の最後まで再送した方がいいのか(TCP)、それは捨てて再送を待つことなく、とりあえず持っている映像を再生したほうがいいのか（DCCP）ということになるかもしれない。
DCCPの検証 (11)
DCCPはデータの再送はおそらくしない…はず。データ以外の再送についてか。
CCID3について調べたがレート制御周りがよく分からない。外からレートを設定するのか、自らレートが一定になるよう制御するのか。
DCCPは次世代UDP、SCTPは次世代TCPと呼ばれているが、どっちかというと、DCCPもSCTPもTCPの亜種だ。UDPの正統進化系譜としてはUDP-Liteこそふさわしいと思う。
現在UDPに残されている作業はブロードキャスト・マルチキャストしかない。
そしてユニキャストならTCP系譜からの進化系と言った方が皆が分かりやすいと思っている。輻輳制御のあるUDPという言い方よりかは、再送とフロー制御のないTCPという方が通りがいい。
(SCTP)Stream Control Transmission Protocolの方が異常な進化だ。複数アドレスを指定可能である点からして、まさに、家庭内複数インターフェースを実現するのに適しているのではないか、と思える位だ。
…最近、IPv6の話題が盛り上がっているが、IPv6が普及する前に、リライアブルIPマルチキャスト・DCCP・SCTPの仕事が終わっていることが望ましいと思う。どれもベストエフォートで非NGNな環境を上手く活用するための必要なプロトコルである。
DCCPの検証 (10)
linux/Documentation/networking/dccp.txtより
request_retries
The number of active connection initiation retries (the number of
Requests minus one) before timing out. In addition, it also governs
the behaviour of the other, passive side: this variable also sets
the number of times DCCP repeats sending a Response when the initial
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
is received after the initial Request). This value should be greater
than 0, suggested is less than 10. Analogue of tcp_syn_retries.retries1
How often a DCCP Response is retransmitted until the listening DCCP
side considers its connecting peer dead. Analogue of tcp_retries1.retries2
The number of times a general DCCP packet is retransmitted. This has
importance for retransmitted acknowledgments and feature negotiation,
data packets are never retransmitted. Analogue of tcp_retries2.
手早い話がそれぞれ、tcp_syn_retries, tcp_retries1, tcp_retries2の類似品だということ。
retries1
listenしているDCCPサイドがその接続しているpeerが死んでいると思うまで、DCCPレスポンスがどれくらい再送されるのか。
retries2
一般的なDCCPパケット再送されるときの数。これは再送されたACKやfeature negotiationに対して重要性を持っており、データパケットは再送されることはない。
DCCPの検証 (9)
2.6.21…素晴らしきLinuxカーネル。
VLCにおける検証でkernel BUGが現れることはなかった。
94MB相当の映像データの伝送を行い、ローカルに保存する設定で93MB相当が保存できた。インターフェースで輻輳を起こし、フレームが捨てられることもなかった。DCCPではRTTでWINDOWを絞っているから、ということだろうか。
査読で「DCCPという仕事を知らないのか」と言われた理由が今なら分かる。これでカスタマイズが効けばかなり使えるような気がする。お次はDCCPのRetry関係の仕事を調べてみようか。
カーネルを変更するたびにカーネルモジュール、研究のためのパッチを適用してのカーネルコンパイル、そして全ての実験のやり直しが必要なのは苦痛だが、それ以上に新しいものを触り、検証し、応用する楽しさがある。
DCCPの検証 (8)
前回のkernel BUGについての情報が入った。
kernel BUG at kernel/timer.c:407!によると、linux-2.6.20 and linux-2.6.21-pre1で発生しうるようだ。日付は2007 Mar 5。かなり近い。
2.6.20で対処するのが面倒なので、2.6.21のroot file systemの方を対処。
The day-to-day thoughts – vmwareと2.6.21によると2.6.21に加えられた変更とvmware上でのSCSIエミュレーションで相性が悪いらしい。確かにbuslogicに代えると上手くいった。
ということなら実機なら上手くいくはず。
意を決してリモートホストに2.6.21を入れた。
…動いた。
DCCPの検証 (7)
そう、アレはttcpの検証が出来たところでVLCの検証を行おうとしたときだ。
以下のメッセージが表示されて何も出来ない。
[code]
————[ cut here ]————
kernel BUG at kernel/timer.c:407!
invalid opcode: 0000 [#6]
SMP
Modules linked in: wlan_scan_sta ath_rate_sample ath_pci wlan ath_hal(P) dccp_ccid3 dccp_tfrc_lib dccp_ccid2 dccp_ipv4 dccp binfmt_misc nfs ipv6 nfsd exportfs lockd nfs_acl sunrpc dm_snapshot dm_mirror dm_mod ide_generic ide_disk i810_audio ac97_codec snd_intel8x0 i2c_i801 psmouse snd_ac97_codec i2c_core rtl8150 rtc tsdev ac97_bus snd_pcm snd_timer snd soundcore parport_pc parport iTCO_wdt serio_raw snd_page_alloc evdev pcspkr ext3 jbd mbcache ide_cd cdrom sd_mod ata_piix usbhid hid ata_generic ahci uhci_hcd ehci_hcd libata scsi_mod piix generic ide_core usbcore tg3 thermal processor fan
CPU: 0
EIP: 0060:[
EFLAGS: 00210246 (2.6.20-1-686 #1)
EIP is at mod_timer+0x6/0x1f
eax: f50f77e0 ebx: f50f7480 ecx: 00102c3b edx: 00102c3b
esi: dfced180 edi: 000003e7 ebp: f50f5f40 esp: f50f5d44
ds: 007b es: 007b ss: 0068
Process lt-vlc (pid: 4581, ti=f50f4000 task=dff88030 task.ti=f50f4000)
Stack: c0235ce7 f50f7480 f8bfdf7b 00200282 00000000 7fffffff c0299764 f50f7480
00000000 c01c37f8 f50f5f48 00000524 00000524 00200246 dfced180 f50f7480
e4de148c f50f5f40 f8bff8fd f50f5d98 7fffffff 00000000 f8b9c000 f50f7480
Call Trace:
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
[
=======================
[/code]
ふっざけんじゃねー
DCCPの検証 (6)
2.6.20で実験を行っている。当初は2.6.21のカーネルを入れて起動しようとしたのだが、root file systemが見つからないということで起動できなかった。
リモートホストの実機のカーネルを入れ代える前に、VMwareで実験するようにしているで、それが原因なのかもしれない。2.6.20はVmwareで単純に入れて成功したので、それを利用している。カーネルはbackportから入れている。
2.6.21と2.6.20のDCCPにどの程度の差分があるのか分からないので、そちらも検証する必要がある。