---(wide-memo-xmpp-wg-report2012-01.txt)----------------- Title: XMPP WG2012年度活動報告書 Authors: 小柏伸夫(ogashiwa@c.kyoai.ac.jp) 佐藤弘崇(satu@sfc.wide.ad.jp) 原田明梨(harada09@c.kyoai.ac.jp) Date: 2012-12-31 1. XMPP WG 2012年度の活動 XMPP WGはIMの標準技術であるXMPP(eXtensible Messaging and Presence)技 術を用いたサービス状況の調査、研究、提案を行い、またそれらを基盤とし た応用研究の実施を目的とするWGである。2012年度には具体的に以下の研究 活動を行った。 o XMPPを利用したCyber-Physicalな世界の実現に関する検討 o XMPPで必須であるDNSのSRVレコードの普及状況調査 o XMPPの信頼性を向上させる手法に関する研究 本報告書では、以降の章において前述の各研究活動について述べる。 2. XMPPを利用したCyber-Physicalな世界の実現に関する検討 2-1. 背景 ネットワークにつながったセンサーの増加により、大量の実世界のデータが 取得されるようになった。さらに、こうしたネットワークにつながったセン サーは生活に溶け込んでおり、それらによって取得されたデータの中にはイ ンターネット上のいわゆるクラウドサービスと連携してその情報を利用者に 提供できるようになっているものもある。 2-1-1. センサーデータの孤立化 ネットワークにつながったセンサーのデータは個々で独立していることが多 く、共有ができていないケースが多々ある。例として、クラウドサービスに つながった体重計を挙げる。この体重計のユーザは毎日このデバイスを使っ て自分の体重データを取得し、そのデータはクラウドサービスに送信されて いる。このユーザが旅行をし、温泉に入り、その後体重を測ろうと備え付け の一般的な体重計で体重を測る。この場合、データはユーザに表示されるの みであり、そのデータはユーザの使うクラウドサービスには送信されなくなっ てしまう。 2-1-2. データの所有権 個人の身の回りにある多くの、本来有用であるはずのネットワークにつながっ たセンサーのデータを自分のものにできないことが問題として挙げられる。 必ずしも身の回りにあるセンサーは自分のものであるとは限らず、設置者が 不明のセンサーも多く存在する。このようなセンサーに自分を紐付け、自分 のデータとして取得できるアーキテクチャが必要となっている。 2-2. 提案アーキテクチャの要件 本研究が提案するアーキテクチャの要件として以下を挙げる。 - センサーと個人を結びつけられるアカウント機構 - 実装の簡易化するための、標準化されたプロトコルの採用 - センシングデータの型の違いを包括する拡張性 - デバイスの所有者が個人に提供するデータのアクセス制限が可能であること まず、センサーと個人を結びつけられるアカウント機構であるが、2-1-2で述 べたデータの所有権の所在を個人にする概念の導入のためである。センシン グデータと個人の結びつきを変えられることが可能であれば、設置者でなく てもセンサーのデータを自分のものとして扱えるようになるからである。 次に、センシングデータの型の違いを包括する拡張性であるが、これはセン サーデバイスのデータの型の違いによるものである。センシングデータはデ バイスによってその型が異なる。例えば温度計については時間、場所、温度 の3次元の要素を入れられることが必要になるし、放射線センサーであれば、 時間、場所、線量、地面からの高さなど4次元の要素を含むことができるこ とが必要となる。以上の拡張が可能なことが要素として重要である。 ３つ目ににデバイスの所有者が個人に提供できるデータのアクセス制限が可 能であることが挙げられる。1.1で述べた体重計の例のような場合では、他 人に自分の体重を知られたくないといったニーズが存在する。こういったデー タへのアクセス制限はデバイス側で所有者がかけられるようにしておくべき であると考える。 最後に、標準化されたプロトコルの採用であるが、センサーデバイス、ユー ザー側のクライアント双方における実装において既存のプロトコルを使うこ とによる作成コストの削減を狙うものである。 2-3. 本アーキテクチャにおける各エンティティの役割 本アーキテクチャにおける各エンティティの役割は以下の通りである。 - ユーザーアカウント: ユーザが持つアカウント - ユーザークライアント: ユーザ側のクライアント センサークライアントとデータを送受信し、データを保存する - センサーアカウント ネットワークにつながったセンサーが持つアカウント - センサークライアント センサー側のクライアントユーザクライアントとデータを送受信する 2-4. 本アーキテクチャにおける各通信の役割 本アーキテクチャにおける各エンティティの役割は以下の通りである。 - フレンド: センサーとユーザーアカウントの紐付け - プレゼンス: 各アカウントの状態を知らせる通信 - メッセージ: センシングデータの転送 / アクチュエーション用コマンドの通信 2-5. システム 以下の図に本アーキテクチャの全体のシステムを示す。 USER1 USER2 | | XMPP Client XMPP Client | | XMPP Server XMPP Server |^ ^| | \------------------------------/ | +----+----------------------------------+------+ | / \ The Internet / \ | +-+------+--------------------------+-------+--+ | | | | Sensor Sensor Sensor Sensor XMPP XMPP XMPP XMPP Client Client Client Client | | | | Sensor Sensor Sensor Sensor 各ユーザ、センサーごとにクライアントが存在する。 センサークライアントはそれぞれのセンサーアカウントを持ち、ユーザアカ ウントのフレンドを待っている状態である。センサークライアントのフレン ド情報はXMPPサーバに保存されていて、フレンドを行う度に書き変わってい く。また、デバイスのアクセス制限についてもクライアント側で行なってい る。 次にユーザークライアントはそれぞれのユーザーアカウントによってXMPPサー バと接続している。これらクライアントはセンサークライアントからのデー タのユーザーへの表示と保存を担当している。 2-5-1. 実際のシステムの動き 以下が、実際のシステムの動きである。 1. ユーザアカウントとセンサーアカウントの結びつけの開始 ユーザーは自分のユーザアカウントとセンサーアカウントをRFIDその他 の手段を使ってデバイスを結びつけを開始する。 2. センサークライアントがユーザアカウントとフレンドになる センサーアカウントはユーザアカウントにフレンドを申請する。ユーザー クライアントは申請を許可する。これでセンサークライアントとユーザー クライアントの間でメッセージのやりとりが行えるようになる。 3. センサークライアントからユーザークライアントへのデータの送信 センサークライアントはセンサーを使ってデータを取得し、それをユー ザークライアントに向かってメッセージの形で送信する。 4. センサーアカウントとユーザーアカウントのフレンドの破棄 センサークライアントはメッセージの送信が完了し、ユーザーがログオ フを指示した場合、ユーザアカウントに対してフレンドの破棄を行う。 2-6. アーキテクチャの実現のために解くべき問題 2-6-1. センシング/アクチュエーションを行うときの個人と機器の動的紐付け センシング/アクチュエーションを行う場合、個人と機器の動的紐付けが必要となる。 解決案としては地理情報によるデバイスとの紐付けが考えている。 2-6-2. 権限管理 デバイスによって紐付けの形が異なる。例えば以下の温度計などの公開され たデータであればそのデータは公共のものであるためアクセス制限をかける 必要はない。しかしながら、体重計のようなものの場合は、利用者が他人に 体重を知られたくないなどのケースが考えられるため、センサーアカウント ごとにデータのアクセス制限をかける必要がある。これに対する解決案とし てはXMPPの拡張を試みる。 2-6-3. センサー/アクチュエータがオフライン時のメッセージの行き先 現在の仕組みではメッセージは次にオンラインになったリソースに届いてし まう。これに対する解決案としては、オフライン時にはサーバ側が代理で返 事をする仕組みを作る。 3. XMPPで必須であるDNSのSRVレコードの普及状況調査 3-1. 概要 XMPPの通信はクライアント・サーバ型に基づいたアーキテクチャに従って行 われている。RFC6120に記述されているように、XMPPクライアントがXMPPサー バへ接続をする際にはSRVレコードを使用する。XMPPの通信で、SRVレコード を使用する目的は2つある。1つ目の目的は、「最初のTCP接続先の決定」で ある。クライアントからXMPPサーバへの最初のTCP接続を確立するために、 DNSサーバは対象となるXMPPサーバのFQDNを少なくとも1つ以上通知するため にSRVレコードを使用する。2つ目の目的は、「負荷分散やサーバ環境の冗長 化」である。SRVレコードを使用することで、少なくとも2つ以上のサーバの FQDNを優先値やウェイト情報とともに通知することが出来る。このように XMPPにおいてSRVレコードは必須な技術として用いられているが、日本では、 SRVレコードをサポートしていないクライアントやサーバが数多く存在する。 そこで、本研究では各国でどの程度SRVレコードが普及しているのかを明確 化するため、SRVレコードの普及率調査を行った。また、普及率調査の結果 著しく普及率が低いと認められた国に対しては、その原因を特定するため原 因調査を行った。 3-2. 問題点 SRVレコードの普及状況における問題には、クライアントOSの標準ライブラ リにおいて、DNSリゾルバの実装がSRVレコードをサポートしていない「クラ イアント側の問題」とDNSホスティングサービスにおいて、SRVレコードをサ ポートしていない「サーバ側の問題」が挙げられる。本研究では、各国の SRVレコードの普及状況を明確化するため、それぞれの実装に委ねられてい るクライアント側の問題については調査対象から除き、サーバ側、すなわち DNS ホスティングサービスを提供している事業者を中心に、各企業の公式サ イトを活用し、サポートしているレコード情報のデータ収集を行った。 3-3. 調査結果 各国のSRVレコードの普及状況及び各レコードの普及率と、SRVレコードの 普及に伴う主な問題を挙げる。 3-3-1. SRVレコード及び各レコードの普及率 SRVレコードの普及状況調査は、APNICから「日本」「オーストラリア」、 ARINから「アメリカ」、RIPE NICから「イギリス」の計4カ国に対して行った。 調査内容としては、調査対象国のDNSホスティングサービス提供事業者に 対して、7つの代表的なDNSレコード「SRV」「A」「AAAA」「NS」「MX」 「CNAME」「TXT」をどの程度サポートしているかを調査した。 調査の結果は以下の通りである。 ・日本： SRV-17% 　 (A-100%, AAAA-16%, MX-100%, NS-60%, CNAME-94%, TXT-72%) ・オーストラリア： SRV-31% 　 (A-100%, AAAA-19%, MX-100%, NS-44%, CNAME-100%, TXT-53%) ・アメリカ： SRV-48% 　 (A-100%, AAAA-38%, MX-97%, NX-48%, CNAME-88%, TXT-59%) ・イギリス： SRV-33% 　 (A-100%, AAAA-33%, MX-100%, NS-53%, CNAME-78%, TXT-67%) *調査を行った企業のうちDNSレコードを公表していた企業は、日本53社/156社 中、オーストラリア32社/48社中、アメリカ29社/55社中、イギリス36社/41社 中である。これらの有効データをもとに調査結果を作成した。 調査の結果から、SRVレコードの普及状況は以下の3つの地域に分かれた。 ● 普及率が著しく低い地域 (ex.日本) ● 比較的普及が進んでいる地域 (ex.オーストラリア,イギリス) ● 普及が進んでいる地域 (ex.アメリカ) 全体的には、SRVレコードが各地域約半数以上の事業者においてサポートされ ていないことがわかる。 また、レコード割合について特徴的な点を以下に挙げる。 ● 日本やイギリスにおいてTXTレコードの普及率が高い ● IPv6のAAAAレコードについてはSRVレコードの普及状況に比例している 3-3-2. SRVレコードの普及に伴う主な問題 SRVレコードの普及率の調査で、著しく低い結果となった日本に対して原因調査 を行ったところ以下の項目が問題点として挙げられた。 ・ DNSホスティングサービス提供事業者側の負荷 実際のDNSホスティングサービスの運用管理の現場では、最近の動向として 効果要請の追求、トラフィックの増加、新しいレコード/データ形式の増加、 DNSを対象とした攻撃の増加があげられ、様々な要因によってDNS運用管理の 負担が増加している。実際に新しいレコードをDNSへ追加するためには、ホ スティングサービス提供事業者側での新しいレコード/データ形式への対応 策として、レコード書式の勉強等DNS運用管理者のスキルアップ、データソー ス管理、データ生成、ゾーンへの反映といった対処が必要となってくる。 SRVレコードは従来からあるAレコード、MXレコードに比べ、比較的新しいレ コードであるため、SRVレコードの追加は、問題視されている事業者の負担 が増える要因になりかねない。さらに、今現在はIPv4枯渇に伴うIPv6の本格 的な普及も進みつつある。本研究の調査結果において、SRVレコードの普及 率とAAAAレコードの普及率が比例していることなどから、IPv6の普及も、前 述した事業者の負担に影響するものと考えられるため、こうした新しい動き に相まってSRVレコードの普及が滞っていると考えられる。 ・ TXTレコードの普及 調査の結果、日本やイギリスにおいては、SRVレコードよりもTXTレコードを サポートしている事業者が数多く存在することが発覚した。このことは、 TXTレコードの利点として、既存のDNSサーバへの変更を必要とせず、比較的 容易に拡張が加えられること、また、負荷分散機能等を除く機能面において はTXTレコードの汎用性によって解決できてしまうことから、多くの企業等 においてSRVレコードの必要性が意識されていないためと考えられる。 ・SRVレコードを使用するサービスの普及率 SRVレコードの認識という面では、SRVレコードを使用したサービスがどの程 度普及しているかということも重要な点となると考えられる。例えば、SRV レコードを使用したサービスの一つであるGoogle Appsの高等教育機関(大 学)における国別普及率は、日本が5〜25万人、オーストラリアが25万〜300 万人、アメリカが300万人以上、イギリスが5〜25万人という数値が見られた。 この普及状況が、調査結果のSRVレコードの普及率とほぼ比例していること から、SRVレコードを使用したサービスが広く普及していないことがSRVレコー ドの普及を遅らせているとも考えられる。 原因調査の結果から、SRVレコードの普及に伴う重要な課題は、大別して以下 の2点に分類できる。 ● DNSホスティングサービス提供事業者側の負荷の問題 ● 使用者側の需要の問題 3-4. 考察 本研究では、普及率の調査とSRVレコードが普及しない原因調査を行った。 原因調査の結果からSRVレコードが、今後数年間で急速に普及することは考 えにくい。また普及率調査の結果から、普及が進んでいない国では言うまで もなく、普及が進んでいる状況下においても、SRVレコードをサポートして いないサーバやクライアントに遭遇する可能性は十分に考えられる。そこで、 SRVレコード未対応の場合には、SRVレコードをサポートしていない場合にお いて使用できる、利便性が高く比較的容易に実装できる解決策が必要となっ てくると言える。利便性の高さについては、XMPPでSRVレコードを使用する 目的でもある優先値やウェイト値の指定等による「TCP接続先の決定」、 「負荷分散やサーバ環境の冗長化」を実現できる解決策が好ましい。また解 決策の導入にあたっては、高い技術力や、多大な労力を費やさなくても解決 できる方法が好まれる。 4. XMPPの信頼性を向上させる手法に関する研究 4-1. 本研究の概要 XMPPは元来からIM技術として用いられてきたが、従来からアプリケーション レベルでのグループ管理やボットのコントロール等、様々な目的で応用され てきた。XMPP技術は、アプリケーションレベルでのグループ管理やグループ に対する統括的な制御を行うシステムを低コストで実現するための基盤技術 としてきわめて有用性が高い。 そこで本研究では、通信における信頼性を向上させることによって、XMPPを 企業や組織内で重要な制御用プロトコルの基盤技術として応用することを目 的とする。 4-2. 信頼性における問題点 XMPPの信頼性は、通常SRVレコードによる「負荷分散やサーバの冗長化」に よって実現されている。(実際の通信では、DNSサーバからXMPPクライアント へ通知する複数のXMPPサーバのホストに、それぞれ優先値とウェイト値を割り 当てて通知する。このとき、優先値の低いホストから優先され、ウェイト フィールドは割り当てられた数値に応じて通信の比重がかけられる。例えば、 同じ機能をもつ3台のサーバのうち処理能力が優れたサーバを1番に優先した い場合は、他の2台よりも低い優先値をつける。もし、優先したいサーバが 何らかの理由で通信できない場合はその次に優先値の低いサーバが優先され る。このとき、他の2台に同じ優先値が割り当てられている場合は、ウェイ トフィールドの値に応じてその比重がかけられる。そのため、ウェイトフィー ルドの値が大きい方が相対的に優先され、その値が同じ場合は同じ比重がか けられる。) しかしながら、SRVレコードをサポートしないDNSホスティングサービスも多 数存在し、SRVレコードによる信頼性の確保が厳しい場合もある。これまで SRVレコード未対応の場合、既存の解決策として、直接ホストを指定する方 法や、TXTレコードを使用した方法が挙げられていた。しかしながら、前者 は不特定多数のユーザーを対象としたサービスなど大規模なサービスにおい ては適切ではなく、後者はTXTレコードをサポートしていない場合において 有効ではない。さらにこれらの解決策は共通して、負荷分散や、冗長化といっ たSRVレコードの特徴である信頼性の役割を果たせない。そこで、本研究で は、SRVレコードが普及していない状況下における新たな信頼性確保の手法 を提案する。さらに、SRVレコードがサポートされている状況下においては、 更なる信頼性向上手法を考案する。 4-3. SRVレコード未対応の場合における解決策の提案 4-3-1. IQスタンザを用いた解決策 本研究では、XMLの要素の一種であり、XMPPのリクエスト/レスポンス型の　 通信において利用されるIQ(Information Query)スタンザを用いた提案を記 述する。 以下に、IQスタンザのスクリプトの例を交えながら提案の概要を説明する。 ●【要求】IQ-getメッセージ（クライアント-サーバ） はじめに、クライアントはサーバに対し、SRVレコードに似た情報を要求す るIQ-getメッセージを送信する。 ●【返信例1】IQ-result メッセージ（サーバ-クライアント） クライアントからIQ-getメッセージを受け取ったサーバは、自分自身がSRV レコードに似た情報を保持していた場合、クライアントに対し、その情報と 共にIQ-resultメッセージを送信する。 ●【返信例2】IQ-error メッセージ（サーバ-クライアント） クライアントからIQ-getメッセージを受け取ったサーバは、自分自身がSRV レコードに似た情報を保持していなかった場合、クライアントに対し、その 情報を保持していないことを伝えるIQ-errorメッセージを送信する。 Sorry! Not support to SRV record query! 4-3-2. 提案の応用 XMLは任意の個数の子要素を含めることができるので、様々な拡張が可能で ある。その特徴を活かし、更なる拡張がこのIQスタンザによって実現できる。 例えば、今回のIQスタンザを利用した提案を応用することにより、負荷分散 における更なる利点を提供することが出来る。その一例として本研究で挙げ るのが「再接続のルールの定義付け」である。例えば、予期せずクライアン トからサーバへのTCP接続が途切れてしまった場合、通常クライアントから サーバに対して一斉に再接続が開始されてしまう。このような事態を防ぐた めにIQスタンザに、ある文字列を記述することによって、あらかじめクライ アントに再接続のルールを定義づけることが出来る。そうすることにより、 更なる負荷分散の実現を図ることが可能となる。本研究では、一つの例とし て「再接続のルールの定義付け」を提案する。 RFC6120によると、クライアントとサーバ間の接続が切断された際の、再接 続の頻度は ”3.3. Reconnection” において以下のように規定されている。 "It can happen that an XMPP server goes offline unexpectedly while servicing TCP connections from connected clients and remote servers. Because the number of such connections can be quite large, the reconnection algorithm employed by entities that seek to reconnect can have a significant impact on software performance and network congestion. If an entity chooses to reconnect, it: o SHOULD set the number of seconds that expire before reconnecting to an unpredictable number between 0 and 60 (this helps to ensure that not all entities attempt to reconnect at exactly the same number of seconds after being disconnected). o SHOULD back off increasingly on the time between subsequent reconnection attempts (e.g., in accordance with "truncated binary exponential backoff" as described in [ETHERNET]) if the first reconnection attempt does not succeed." 上記のアルゴリズムは、接続が切断された際、大量のクライアントが一斉に 再接続をすることによるサーバの負荷の増大を避けるためにある。しかしな がら、本研究で提案している拡張を応用し、各クライアントにそれぞれ異な る”再接続待ち時間”を通知することで、上記のアルゴリズムを利用しなくて も輻輳を避けることが出来る。さらに、利用頻度の高いユーザーに対して 「短い再接続待ち時間」を通知し、利用頻度の低いユーザーには「長い再接 続待ち時間」を通知するなどによって負荷分散における利便性を高めること も可能となる。 以下に、IQスタンザのスクリプトの例を交えながら上記の応用例を説明する。 ●(サーバ-クライアント) 以下の例では、サーバは利用頻度の高いクライアントAに対して5秒で再接続 を許可している。 ●(サーバ-クライアント) 以下の例では、利用頻度の低いクライアントBに対して30秒で再接続を許可 している。 このように予期せぬ事故によって突然クライアントからサーバへの接続が途 切れてしまった際、再接続までの待ち時間をそれぞれのクライアントに対し て指定することで、一斉にクライアントからサーバに対してアクセスが集中 することを防ぎ、複数の接続要求を分散させることが出来る。 4-4. 新たな信頼性向上手法の考案 ここまでは、SRVレコードが普及していない場合における信頼性の保証手法 であったが、SRVレコードが当然のように使用できる状況においては、更な る信頼性向上手法が考えられる。 現在のXMPPの仕様では、クライアントが一つのユーザアカウントで複数のサー バに同時に接続することは想定されていない。そのため、現在ではサーバや セッションに問題が発生した後に、クライアントが異なるサーバにセッショ ンを確立し直すという挙動が一般的になっており、複数のサーバを準備して おくことが充分な高信頼手法として応用されていない。 そこで本研究では、新たな信頼性向上手法として、単一のアカウントで複数 のサーバに対して同時にTCP接続を確立しておく手法を考案した。クライア ントは、初めにSRVレコードによって通知された全てのXMPPサーバに対して あらかじめTCPコネクションを張っておくことで、それらのTCP接続を以下の ように利用することが可能となる。 ● 死活監視 - 複数のTCP接続上でサーバ側からクライアントに対して死活監 視のためのメッセージ送受信を行うことにより、より確実にクライアントの 状態を把握することが可能となる。 ● 高速な切り替え - 死活監視の結果に応じて、より適切なTCP接続を選択し てメッセージ送受信に移用する。これにより、特定のTCP接続の状態が悪化 した場合であっても高速にメッセージ送受信を復旧することが可能となる。 ● 一斉送信 - 複数のTCP接続上で同じメッセージを一斉に送信し受信側では 最も早く到着したメッセージを採用する。これは一般的には Bi-casting と 呼ばれる手法である。これにより、送受信尾性能の向上と、メッセージの欠 落の可能性の削減を行い、信頼性の向上を図ることが可能となる。 ● ロードバランス - 前述の Bi-casting は送受信時の通信負荷が低い場合 には実施可能であるが、送受信時の通信負荷が高い場合には、複数のTCP接 続上でメッセージを分散して送受信する。これにより、サーバ側の負荷を削 除し、システム全体における信頼性向上を図ることが可能となる。 機器の管理や様々な通信要素のグループ管理や一括制御のシステムの構築時 に、本研究で考案した拡張型 XMPP 技術を用ることで、信頼性を必要とする 企業内システムや大学内システムにおいて、極めて低コストながらも多種多 様な機器を柔軟にグループ化し、一括制御できるシステムが次々と構築でき ると期待される。 4-5. 今後の展望 今現在は、XMPPの技術は主にIM技術として使用されているが、本研究で提案 したSRVレコード未対応の場合の信頼性向上手法や新たな信頼性向上手法の 考案を用いることによって、XMPPの活躍の場がビジネスや教育の現場にまで 広がることが期待出来る。XMPPの信頼性を向上させる手法に関する研究の今 後の展望として、本研究で考案した、信頼性向上手法の実現に向けて研究を 推進していく。 5. まとめ 今年度は、以下の研究を遂行した。 o XMPPを利用したCyber-Physicalな世界の実現に関する検討 o XMPPで必須であるDNSのSRVレコードの普及状況調査 o XMPPの信頼性を向上させる手法に関する研究 XMPP技術は、現在ではGoogle Talkに用いられ、また、世界最大規模のSNSサー ビスにおいても利用されており、メッセージング技術の標準という位置づけ においては既に安定利用され始めている。しかしながら、XMPP技術が潜在的 に持つ応用の可能性や高い利便性についてはまだ改善の余地、検討の余地が 残されている部分が多々見受けられる。 今年度は、XMPP技術を用いた物理的な世界とのつながり、高信頼性の確保や 冗長化技術の検討、を進めてきた。今後はさらに、より利便性の高いユーザ インターフェースの検討や、XMPPサーバの実運用を通した応用的且つ実利用 への適用に向けた検討等の研究を遂行していく予定である。 --------------------------------------------------------------