SSDP draft v1.03和訳中

SSDPのドラフトv1.03を和訳中。

  1. Introduction [Ed. Note: 私の経験では、仕様書を素早くそしてうまく記述する最善の方法の一つは、 提案する解決法補や設計した基本原則で解決する問題の詳述を提供することだ。 Larry MasinterがWebDav WGに提案した際に、私はこれを3つのパートの設計要素に分けた。 そのためにも、私はこの仕様書を同様の方法で分割した。 一旦仕様書が十分に熟成すると、問題の詳細と設計された原則の章は、別のドキュメントに分割し、提案する解決策は標準化のために含まれている。]

このドキュメントは、読み手がRFC2616(HTTP/1.1), HTTPUDP, GENA, MAN, RFC2365( Administratively Scoped IP Multicast)に詳しいことを想定している。

2.1 Problem Statement HTTPクライアントとHTTPリソースに許可する必要のあるメカニズムは、 LAN内でお互いを発見することである。 これは、HTTPクライアントは特定のサービスを必要としてもよい。 それは、一つもしくはより多くのHTTPリソースによって提供されるかもしれない。 クライアントは、HTTPリソースがクライアントの望むサービスを提供しているという事実を発見するメカニズムを必要とする。

この仕様書の目的として、先ほど述べたHTTPクライアントはSSDPクライアントとして言及されている。 先ほど述べられたHTTPリソースは、SSDPサービスとして言及されることになる。

単純なケースでは、この発見メカニズムは、設定も運用も操作も無しで動作する必要がある。 例えば、ユーザがホームネットワークをセットアップしたり、小規模な会社がLANをセットアップする場合、プリンターやスキャナ、Faxといった機器のSSDPサービスを発見するためにSSDPが利用されるまでは、彼らはSSDPの設定を要求されてはならない。

SSDPにとって、マルチキャストスコープブリッジングや先進的なクエリのを提供することがゴールではない。

2.2 Proposed Solution 2.2.1 Message Flow on the SSDP Multicast Channel 以下はSSDPの実装に用いられるメッセージの概要である。

SSDPクライアントは、予約済みのlocal administrative scopeであるマルチキャストアドレスの239.255.255.250のSSDPポート(IANAからまだ割り当てられていない)を利用してSSDPサービスを発見する。

簡潔さの目的のため、SSDPはlocal administrative scope multicast addressを予約した。 ポートはSSDPマルチキャストチャネル/Portとして言及される予定である。

発見は、あるSSDPクライアントがHTTP UDP discoveryリクエストをSSDPマルチキャストチャネル/Portにマルチキャストする際に起こる。 このようなDiscovery requestを聞くために、SSDPサービスはSSDPマルチキャストチャネルをリッスンする。 SSDPサービスがサービスにマッチしたHTTP UDP Discovery requestを聞いた場合、 ユニキャストのHTTP UDP responseを返す。

SSDPサービスがSSDP multicast channelに、それらの生存を示すためにHTTP UDP notificationアナウンスを送っても良い。

従って、2タイプのSSDP resultがSSDP multicast channelを超えて送られる。 1つめはdiscovery requestで、SSDPclientがSSDPサービスを探すために送信する。 2つめはpresence announceで、SSDPサービスがその存在を示すために送信する。

2.2.2 SSDP Discovery Information Caching Model 以下はSSDPシステムで提供されるデータの概要である。

サービスは、サービスタイプのURIとユニークサービスネーム(USN) URIのペアによって特定される。

サービスタイプは、冷蔵庫やcloc/radioのようにサービスの種類を特定する。 的確なサービスタイプの重要性は、この仕様書のスコープ外である。 この仕様書のために、サービスタイプは、サービスを特定の種類のサービスと関連づける、不明確な識別子とした。

USNは、あるサービスの特定のインスタンスをはっきり識別するURLである。 USNは、同じサービスタイプの2つのサービスを区別するために利用される。

サービスタイプとUSN両方を提供することに加え、discovery resultsとpresence announcementsは共にexpirationとlocation informationを提供する。

Location informationは特定のサービスにどのようにアクセスすべきかを決定する。 discovery responseもしくはpresence announcementには、 一つもしくは複数のURIが含まれる。

Expiration informationはSSDP clientのキャッシュの中に、 そのサービスについてどの程度の期間情報を保持すべきかを示す。 一旦entryが期限切れになると、SSDPクライアントのキャッシュから削除される。

従って、SSDPクライアントサービスキャッシュは、このように見えるだろう。

USN URI Service Type URI Expiration Location
upnp:uuid:k91… upnp:clockradio 3 days http://foo.com/cr
uuid:x7z… ms:wince 1 week http://msce/win

上の例では、URN URIは実際には両方ともUUIDである。

announcementもしくはdiscovery responseが受信され、 そのUSNが既にキャッシュに存在するエントリと一致する場合、 該当のキャッシュは完全にannouncementもしくはdiscovery responseの情報に置き換えられる。

2.3 Design Rationale [Ed. Note: 私の経験では、設計の基本原則を説明する最も強力な方法の一つは、 question/answer形式で行う事だ。 それ故、その形式を以下で利用する。

2.3.1 Message Flow on the SSDP Multicast Channel マルチキャストの利用の背景となる設計の根拠のより多くの情報としてsection8.3を参照してください。

2.3.1.1 Why use multicast for communication? 誰も設定を行っていない状況においても動作するコミュニケーションの解決策を必要としている。 最も簡単な解決策は、発見サーバを構築することであろう。 しかし、発見サーバを誰が構築するのか? 誰がメンテナンスを行うのか? 誰も何が発見されるのか分からない状況ですら動作する解決策が必要である。 マルチキャストを用いることで、”party channel”に相当するモノを手に入れることができる。 誰もがチャネルを握り、自分の必要なものを叫び、誰もがそれを聞く。 これは設定の心配がないことを意味する。 もちろんこれにより、この仕様書を通して指摘を行う他の問題も止めることができる。

2.3.1.2 Why use a local administrative scope multicast address? マルチキャストは、リンクローカルからはるばるインターネット全体まで、 多くのスコープで入ってくる。 我々のゴールは、インターネット全体ではなく、LAN内での発見を提供することである。 LANはしばしばブリッジングやルーティングが行われる。 従って、リンクローカルマルチキャストスコープでは制限が強すぎる。 次のレベルはlocal administrative scopeである。 この考え方は、あなたのシステム管理者が、どれだけ多くのマシンを同じグループとすべきで一つのユニットと考えるべきだと決めたかである。 これは、ローカルの発見プロトコルにとって、理想的なスコープであると考えられる。 (ASまたはドメイン内全部に届く)

2.3.1.3 Why does SSDP support both service discovery request as well as service presence announcements? 幾つかの発見プロトコルはdiscovery requestのみをサポートしている。 周囲に何が居るか発見するために、クライアントはリクエストを送出しなければならない。 このようなソリューションの悪い点は、通信負荷になりがちだということである。 例えば、家に居る全てのVCRを発見したいとする。 しかしながら、プログラムが開始した後に、新しいVCRを買ったユーザがそれを接続した。 我々がそのデバイスを発見し、ユーザのスクリーンに表示するたった一つの方法は、 継続的にdiscovery requestを継続的に送信することである。 ネットワークに接続している全てのクライアントが、それらの利用しているサービスの新たなクライアントが接続されるのを見逃さないように、 discovery requestの連発を送信し続けているところを想像してほしい。

他のシステムは対極の方法を利用し、announcementだけをサポートする。 それ故、別のユーザがVCR displayウィンドウを開いたときに、 我々はアナウンスをリスニングするだけである。 このようなシステムでは、全てのサービスは、誰も聞き逃さないことを明確にするために、 一定間隔でアナウンスメントのstreamを送信し続けなければならない。 ユーザは世界中で最も慣用深い人々ではない。 各々のサービスは恐らく、少なくとも数秒に一回はannounceを送信する必要がある。 この定期的なストリームのトラフィックは、ネットワークの効率にとって脅威である。 とりわけイーサネットのような共有コネクションにおいては。

SSDPは混合のアプローチを取ることにしたので、discoveryとannouncementを送信する。 これは非常に効果を発揮する。サービスが最初にオンラインになったとき、 全員がその接続を認識するために、announcementを送出する。 その時点で、それがオフラインになったり、状態の変化、キャッシュのエントリが期限切れになる場合を除いて、 それ以上別のannouncementを送信する必要は無い。 オンラインになるどのクライアントも、サービスがオンラインになった後、 discovery requestを送信することで目的のサービスを発見することができる。 その後その後でオンラインになる全てのサービスが、自分自身がオンラインになったことを知らせるので、 どのサービスのクライアントも、discorvery requestを継続して送信する必要は一切無い。 最終結果として、誰も継続的なmessageのstreamを送る必要が無い。 システム全体でイベントドリブンであり、状態が変化した際だけメッセージを送信する。 しかしながら、そのコストとして、プロトコルは複雑になる。 SSDPがとても大規模なネットワークでも成功できるようにするためには、 これは払う価値のあるコストであると感じている。

2.3.1.4 Doesn’t the caching information turn SSDP back into a “announcement driven protocol?” announcementしかサポートしない発見プロトコルは一般的に、 数秒ごとにannouncementを送信することをサービスに要求する。 一方、ユーザスクリーンがこれらのサービスにより利用可能になった情報をアップデートするには長い時間がかかる

一方SSDPは、サービスがクライアントに、サービスがどの程度の時間存在すると想定していいかを伝えられる。 それ故サービスは、サービスのインターバルの時間を、秒、分、日、周、月、もしくは年単位に出すらも設定できる。

クライアントは、それらがdiscoveryを実行できるので、キャッシュアップデートのメッセージを待たなくても良い。

2.3.2 SSDP Discovery Information Caching Model 2.3.2.1 Why do we needs USNs, isn’t the location good enough? サービスがそれ自体を公告しているとき、大抵はそれがどこで見つけられるか特定するためのlocationの情報を含む。 しかしながら、その位置情報は、時間経過によって変わるし変えても良い。 例えば、ユーザはDNS名の割当の変更を決定するかも知れない。 USNではなくlocationに依存するべきだろうか? サービスのlocationが変更された時、我々が新たなサービスを探しているかも知れない。 これはユーザ経験を台無しにしかねない。 例えば、ユーザが、彼らのVCRベースのインターネットと連携するスケジューラーのPCプログラムをセットアップするのを想像してほしい。 もしユーザがVCRの名前を工場出荷状態から何かしらユーザフレンドリーなものに変更することにした場合、 locationベースのシステムはVCRへの月席情報を喪失する。 ユニークIDを用いることで、VCRはユーザ名の変更を気にせず追跡することが可能になる。 ユーザは望むときにVCR名の変更が可能であるし、VCRプログラミングアプリケーションは、正しいVCRをプログラムできる。

2.3.2.2 Why are USNs URIs and why are they required to be unique across the entire URI namespace for all time? 一般的に、ユニバーサルで利用できるユニークな名前を作ることは、しばしばとてもよいアイデアであると判明する。 UUIDのようなメカニズムで、グローバルで利用できるユニークな名前を分散的な方法でカンタンに作ることができる。 サービスが継続的に移動するかもしれないので、このケースでは、USNをユニークにするととても便利である。 もしそれらを追跡しようとすれば、変化せず他のサービスと混乱しない識別子が必要である。

それらがインターネット上で利用するための名前空間のデファクトであるという理由で、URIを採用する。 名前のようなものを使いたい時はいつでも、単にURIを利用するのが簡単である。

  1. Terminology SSDP Client - HTTPクライアントで、サービスを利用する SSDP Service - HTTPリソースで、SSDPクライアントが利用するサービスを提供する SSDP TYpe - 特定のサービスの機能の種類を特定するためのURI USN - URIの名前空間全体に於いて、いついかなる時でもユニークであることが保証されているURI。  同一のサービスタイプURIのサービスを識別するのに利用する。

加えて、MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONALはRFC2119に沿って利用する。

  1. SSDP Discovery Requests 4.1 Problem Statement SSDPクライアントが望むSSDPサービスを発見するために必要である。

4.2 Proposed Solution SEARCHメソッドは、DSALによって紹介されたが、 SSDP discoveryのために提供されるMANメカニズムのを利用した拡張である。

SSDP SEARCH拡張は、ssdp:discoverというURIによって特定される。

簡潔さの目的のため、HTTP SEARCHメソッドは、SSDP:discoverの機能性を拡張される。

ssdp:discoverリクエストは、STヘッダーを含まなければならない。 ssdp:discoverリクエストは、bodyを含んでも良い。 しかし、bodyはHTTPサービスとして理解されない場合、無視される。

STヘッダーは一つのURIを含む。 SSDPクライアントは、発見したいサービスを特定するために、STヘッダーを利用しても良い。

この仕様書は、HTTP Multicast UDP上でのssdp discoverリクエストの利用についてのみ記述する。 将来の仕様書ではssdp:discoverリクエストのHTTP TCP上での送信についての拡張も期待される。

SSDPマルチキャストportに送信されるssdp:discover requestは、 request-URIにを持たなければならない。 将来の将来の仕様書では、他のrequest-URIも許可されるだろうことに注意してほしい。 この仕様書をベースとした実装では、SSDPマルチキャストportへのssdp:discoverリクエストでは、 request-URIがではないリスエスとは無視する準備をしなければならない。

STヘッダーの値に合致するサービスタイプを持つSSDPサービスだけは、 SSDP multicast portへのssdp:discover requestに返信しても良い。

SSDP multicast portへのssdp:discover requestへの返信は、 ssdp:discover requestの送信元IPアドレス/ポートへ送られる。 ssdp:discover requestへの返信は、Locationと/もしくはALヘッダーを通して拡張された サービスlocationを含むべきである。 ssdp:discover requestへの成功した応答は、STとUSNヘッダーを含まなければならない。

ssdp:discover requestへの応答は、cache-control:max-ageかExpires headerを含むべきである。 両方が存在する場合、HTTP/1.1によって指定された順番で処理される。 chache-controlはExpires headerよりも優先される。 どちらも存在しなければ、その応答は、SSDPクライアントにキャッシュされてはならない。

4.2.1.1 Example M-SEARCH * HTTP/1.1 S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Host: 239.255.255.250:reservedSSDPport Man: “ssdp:discover” ST: ge:fridge MX: 3 HTTP/1.1 200 OK S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6 Ext: Cache-Control: no-cache=”Ext”, max-age = 5000 ST: ge:fridge USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6 AL:

4.3 Design Rationale 4.3.1 Why is the ST header so limited? 適切なレベルの探索能力を決定することは、望みの薄い仕事である。 そこで我々は、絶対的最小で、一つのわかりにくいtokenで、何が起こっているのか分かるものに削減した。 結果として、そこまではうまくいった。 沢山の素晴らしい特徴が提供されないが、それらの殆どは、 検索エンジンやディレクトリに要求される、高等なqueryやスコープのようなものである。 このレベルの可用性は、我々が明確にSSDPのターゲットとする多くの単純なデバイスの限界を超える。 検索機能がall or notiongタイプの状態のようであることを除けば。 何も考えない単純検索をしたい場合かSQL classの検索システムに近い高度な検索のいずれかを必要とする。 SSDPを両方の世界で最低のモノにする代わりに、無価値で単純な検索問題に注目した。 そして、directory folkにより発展的な材料を加えた。

4.3.2 If we are using the SEARCH method why aren’t you using the DASL search syntax? 我々は、、トースターオーブンにXMLを習得することを強いる理由を思いつけなかった。 一人前のDASL search syntaxが提供する特徴は、本当に荘厳なもので、 我々のシンプルなシナリオを遙かに超えている。 DASLが発展的な探索シナリオにとって、より好ましい解決策になることを、心の底から期待している。 しかし、このドラフトで求めるものではない。

4.3.3 Why can we only specify one search type in the ST header of a ssdp:discover request? 我々は、可能な限りシンプルに始めたかった。 そして、足をばたばたさせて泣き叫びながら、追加の複雑さを加えることを強制された。 最も単純な解決策は、STヘッダーに単一の値のみを許可することだ。 複数の値をSTヘッダーに設定することを許可したら、誰かが機能性を追加しようとするだろうことを懸念している。 複数の値をSTヘッダーに設定することを制限して、最小限のバイト数にすることが、 プロトコルをシンプルにするためのより良い方法に思われる。

4.3.4 Why do we only provide support for multicast UDP, not TCP, ssdp:discover requests? discovery protocolを動かそうと

我々はdiscovery protocolを動かしたいものを決めただけで、 そして、TCPでdiscovery protocolを羽後書くことを望まなかっただけだ。 TCP discoveryが本当に動くようにすることを除けば、 複合のresponseを扱えるようにしたいということは、 複合のフォーマット(恐らくXMLやより扱いたいもの)を使いたいということを意味する。 ゆくゆくはHTTP TCPリクエストを利用してサービスを発見したりするサーバ上のSSDP portに成長させたいと考えている。 しかし、これは将来の拡張として記述する。

4.3.5 Why do we require that responses without caching information not be cached at all? caching infomationを提供しないサービスを取り扱えるようにするために、 さまざまなヒューリスティックを説明する事を試みるよりも遙かに簡単だからだ。

  1. SSDP Presence Announcements 5.1 Problem Statement SSDPサービスが興味のあるSSDPクライアントに自分の存在を知らせるためのメカニズムが必要である。

SSDPサービスがそれらに関連するキャッシュエントリの期限の更新をするためのメカニズムが必要である。

SSDPサービスの位置が変更された場合に、関連するSSDPクライアントに通知するためのメカニズムが必要である。

関連するSSDPクライアントに、SSDPサービスがそれら自身を停止したことを知らせるためのメカニズムが必要である。

5.2 Proposed Solution 5.2.1 ssdp:alive SSDPサービスはネットワーク上のそれらの存在を、NTS Valueをssdp:aliveに利用した GENA NotifyメソッドをSSDP multicast portへ送信することで宣言しても良い。

簡潔さを目的として、NTS valueにssdp:aliveを利用したHTTP Notify methodsは、 以降ssdp:alive requestとして言及する。

SSDP clientのキャッシュに既に存在するエントリのUSNと一致するUSNを持つssdp:alive requestが受信されたとき、 そのUSNに関連する全ての情報がssdp:alive requestに含まれる情報に置き換えられる。 それ故、ssdp:alive requestは、location informationの更新や、 キャッシュエントリの期限切れを防ぐ目的で利用することができる。

ssdp:alive requestに含まれるNTの値は、サービスのservice typeが設定されなければならない。 ssdp:alive requestはSSDPサービスのUSNが設定されたUSNヘッダを含まなければならない。

ssdp:alive requestはLocationと/もしくはALヘッダーを含むべきである。 もしLAN内でDNSのサポートがない場合、少なくとも一つのlocationはIPアドレスにすべきである。

ssdp:alive requestはchache-control:max-ageかExpires headerを含むべきである。 両方が存在する場合、HTTP/1.1の仕様に沿って処理され、chache-controlが優先される。 両方とも含まれていない場合、SSDP clientはそれを無視する。

SSDP multicast channel/portへ送信されたssdp:aliveへの返信は行われない。

5.2.1.1 Example NOTIFY * HTTP/1.1 Host: 239.255.255.250:reservedSSDPport NT: blenderassociation:blender NTS: ssdp:alive USN: someunique:idscheme3 AL: Cache-Control: max-age = 7393

5.2.2 ssdp:byebye NTS valueにssdp:byebyeをセットしたGENA Notify methodをSSDP multicast channel/portへ送信することで、 SSDP serviceはそれらの意思を示すことができる。

簡潔さのために、NTS valueにssdp:byebyeを設定したHTTP Notify methodをssdp:byebye requestと呼ぶ。

ssdp:byebye requestのNTの値は、サービスのservice typeを設定しなければならない。 ssdp:byebye requestはSSDPサービスのUSNをセットしたUSNヘッダーを含まなければならない。

SSDP multicast channel/portへ送信されたssdp:byebyeには返信しない。

ssdp:byebye requestが受信されたとき、該当のUSNに関係する全てのキャッシュ情報は削除される。

5.2.2.1 Example NOTIFY * HTTP/1.1 Host: 239.255.255.250:reservedSSDPport NT: someunique:idscheme3 NTS: ssdp:byebye USN: someunique:idscheme3

5.3 Design Rationale 5.3.1 Why are we using GENA NOTIFY requests? いくつかのnotification formatを利用する必要がある。そして、GENAは他に劣らず素晴らしい。 次に、GENAは、notificationの登録をするためのフレームワークを提供する。 これは、SSDPサービスがステータスアップデートを提供するために必要なものであり、 大部分は実在しないインターネットマルチキャストインフラに依存することなく、インターネット越しに送信することができる。

5.3.2 Why is there no response to the ssdp:alive/ssdp:byebye requests sent to the SSDP multicast channel/port? 何のresponseを送信するんだ? SSDPクライアントは多数存在するだろうから、 SSDPクライアントに”我々はあなたのnotificationを受信しました”というresponseを送信させるべきポイントはあまりない。

5.3.3 Could NTS value other than ssdp:alive/ssdp:byebye be sent to the SSDP multicast channel/port? はい。

5.3.4 Why do we include the NT header on ssdp:byebye requests? USNしか活用できる情報がないので、技術的には必要ない。 しかし、我々はGENAのフォーマットを貼り付けたい。GENAのフォーマットではNTヘッダーは必要である。 実際には、NTヘッダーを含めるようにする要求は、次のイシューの結論である。

5.3.5 Souldn’t hte NT and NTS value be switched? その通りである。 ssdp:aliveやssdp:byebyeのようなコマンドは、NT valuesやサービスタイプであるべきであるし、 必要であれば、NTSであるべきである。 現在の混在した状態は、NTヘッダーが現在のUSNのように利用されていた以前の設計の結果である。 これは本当は変更したい。

  1. SSDP Auto-Shut-Off Algorithm 6.1 Problem Statement SSDPが既存のネットワークに壊滅的な打撃を与えるようなハイレベルのトラフィックを 引き起こさないということを保証するメカニズムが必要である。

6.2 Proposed Solution [Ed. Note: 我々から提案する案はあるが、まだ少し荒いので、メーリングリストで議論してから掲載する]

6.3 Design Rationale 6.3.1 Why do we need an auto-shut-off algorithm? SSDPのユーザが、いくつかのssdp:discover requestを送信する期間に、 どの程度の帯域幅を利用するか知るためのアルゴリズムは、 DR = ssdp:discover requestを送信するSSDP clientの数 RS = ssdp:discover requestに返答するサービスの数 AM = ssdp:discover requests/responsesの平均サイズ TP = questionの期間

とすると ((DR3 + DR9RS)AM)/TP となる。

3というのは、ssdp:discover requestを送信する数である。 9というのはssdp:discover requestに対して送信されるユニキャストresponseの数である。 3つのオリジナルrequestを受信した場合の最悪のケースから計算している。

では、実世界での最悪のシナリオについて見てみよう。 いくつかの会社では、voiceやvideoストリーミングのようなマルチキャストベースのサービスをカンタンに設定するために、 local administrative multicast scopeを会社全体を包含するように設定している。 これは、100,000台のマシンを一つのadministrative multicast scopeに設定する事言うことを意味する。 電源障害があり、全てのマシンが同時にバックアップされた場合を考えよう。 更に、それら全てがプリンタのlocation cacheを更新しようとしてssdp:discover requestを送信することを想定する。 最後に、大体5000台のプリンターがネットワークに接続されているところを想像してほしい。 ssdp:discovery requestは30秒の間に送信されるものと見積もって単純化すると

DR = 100,000 requesting clients RS = 5000 services AM = 512 bytes TP = 30 seconds

((1000003+10000095000)512)/30 = 76805120000 bytes/s = 585976.5625 Megabits per second

これはとてつもない量である。

もう少しリーズナブルなサイズのネットワークについて考える。 1000のクライアントと50のプリンタについて考えると

DR = 1000 requesting clients RS = 50 services AM = 512 bytes TP = 30 seconds

((10003+1000950)512)/30 = 7731200 bytes/s = 59 Mbps

これはとてつもない量のように見える。しかし、30秒で全てを裁いた時の例である。 リブートしたときに送信されるSSDPの情報全ては、59 * 30 = 1770Mbになる。 それ故、10Mbpsのネットワークは、実効値が5Mbpsだとすると、 1770 / 5 = 354秒 = 6分もの間ネットワークがダウンすることになる。

これは、1000台のクライアントと50のサービスが一斉に接続しようとした最悪のケースについてであるが、 悪い見積もりではない。

両方のケースで、最悪のケースのシナリオであることは明白で、ネットワークストームは避けなければならない。 それゆえ、ネットワークストームが起こる前にSSDPを無効化する方法が必要である。

6.3.2 Why not just require everyone to support directories and thus get around the scaling issue? 多くの製造者は、クライアントとサービスに全てのプロトコルを実装しようとするかも知れない。 もしあなたのネットワーク管理者が、SSDPをサポートするいくつかのクライアントとサービスを購入したが、 SSDPをサポートしていることに気付いていないとする。 それ故、もしdirectory supportを要求すると、多くのケースが考えられる。 SSDPクライアントとサービスが、誰にも知らせずにうっかり終了すると、問題が発生する。

  1. ssdp:all 7.1 Problem Statement クライアントが、特定のSSDP multicast channel/portで利用できる全てのサービスを列挙することができるのが望ましい。

7.2 Proposed Solution 全てのSSDPサービスは、ST valueがそれらのサービスタイプだったのと同じように、 ssdp:allにSTバリューを設定したSSDP multicast channel/portへのSEARCH requestに応答しなければならない。

完結にするため、ssdp:allにSTを設定したSEARCH requestを、ssdp:all requestと呼ぶ。

7.3 Design Rationale 7.3.1 Why would anyone want to enumerate all services? この特徴は、ほぼネットワーク分析ツールのためのものだ。 これはまた、ディレクトリがSSDP awareな場合にとても有効だと分かるだろう。 全てのサービスを発見できるし、それらの情報を記録し、 local administrative multicast scoreの外でもその情報を有効にすることができる。

  1. SSDP Reserved Multicast Channel 8.1 Problem Statement SSDPは、SSDPを受け入れるクライアントとサービスによってのみ利用されることが保証される local administrative multicast channelを必要とする

8.2 Proposed Solution IANAはSSDPで排他的に利用するために5つのマルチキャストアドレスを予約している。 このバージョンのSSDPによって利用されるlocal administrative scopeは239.255.255.250である。

SSDPのreserved portを申し込んでいるが、IANAからはまだ返答がない。

8.3 Design Rationale 8.3.1 Why didn’t SSDP just get a statuc local administrative scope address rather than a relative address? SSDPがdirectoryのような基本的なシステムサービスを発見するために利用されるかもしれないので、我々はrelative addressを取得した。 このケースでは、directoryを発見することができない。 もしあなたがローカルスコープでdirectoryを発見できなければ、 より広いmulticast scopeを試したいと思うかも知れない。 これはまさしく、MALLOCによって可能になった類の機能である。 MALLOCは全てのマルチキャストスコープのエミュレートを許可する。 SSDPクライアントが、サービスを発見するために次第に大きなスコープを試せるようになる。 しかしながら、この次第に大きくするdiscoveryは、SSDPがrelative addressを利用する場合のみ可能である。

8.3.2 Why does SSDP need to use a port other than 80? Berkley Socketの設計にバグがあり、WinSockにもまた継承されている。 以下のようなバグである。 local unicast addressで同じポートを取得しない限り、特定のマルチキャストアドレスで特定のポートを握ることができない。

この結果、もし我々が80番をSSDPのマルチキャストスコープで利用しようとすると、 我々はSSDPソフトウェアに80番ポートを握ることを要求することになる。 これはSSDPがHTTPサーバ機能を持たないマシンでのみしか実装出来ないか、 HTTPサーバの拡張としてSSDPをサポートしないといけないということになる。

これは不要な制限であると考える。 それゆえ、80番以外のポートでSSDP multicast channelを動かすことを選択している。

Written on October 15, 2013