パート III SLP (トピック)

このパートでは、サービスロケーションプロトコル (SLP) サービスの概要、計画、作業、およびリファレンス情報について説明します。

第 7 章 SLP (概要)

サービスロケーションプロトコル (SLP) は、SLP が使用できるネットワークサービスを検出しそれに対応するための、移植性が高くプラットフォームに依存しないフレームワークを提供します。この章では、SLP のアーキテクチャーの概要と、IP イントラネットに対応する SLP の Solaris での実装について説明します。

• 「SLP のアーキテクチャー」

• 「SLP の実装」

SLP のアーキテクチャー

この節では、SLP の基本的な処理を示し、SLP の管理で使用されるエージェントとプロセスについて説明します。

SLP は、次のサービスを自動的に行い、設定はほとんどあるいはまったく必要ありません。

• クライアントアプリケーションがサービスへのアクセスに必要な情報を要求する

• プリンタ、ファイルサーバー、ビデオカメラ、HTTP サーバーなどのネットワークのハードウェアデバイスやソフトウェアサーバーにサービスを通知する

• 主サーバーの障害からの管理された回復

また、SLP の動作を管理、調整するために、必要に応じて次のことを実行できます。

• サービスとユーザーを論理グループや機能グループから構成されるスコープに編成する

• SLP のロギングを有効にして、ネットワーク上の SLP 動作の監視とトラブルシューティングを行う

• SLP のタイミングパラメータを調整して、パフォーマンスの向上とスケーラビリティーの拡張を行う

• SLP がマルチキャストルーティングに対応していないネットワークに配置されている場合、マルチキャストメッセージの送信や処理を行わないように SLP を構成する

• SLP のディレクトリエージェントを配置して、スケーラビリティーとパフォーマンスを改善する

SLP 設計の概要

SLP ライブラリは、サービスをネットワークで検出するための情報を、サービスを通知するネットワーク対応のエージェントに与えます。SLP エージェントは、サービスの種類と場所に関する最新情報を保持します。これらのエージェントはプロキシ登録を使用することで、SLP が直接使用できないサービスを通知することもできます。詳細は、第 10 章レガシーサービスの組み込みを参照してください。

クライアントアプリケーションは、SLP ライブラリに依頼して、サービスを通知するエージェントに直接要求を出してもらいます。

SLP エージェントとプロセス

次の表では、SLP エージェントについて説明します。ここで使用する用語の詳細な定義は、用語集を参照してください。

次の図は、SLP アーキテクチャーを実装する、基本的なエージェントおよびプロセスを示しています。図は、SLP のデフォルトの配置を表しています。特別な構成はまったく行われていません。UA と SA の 2 つのエージェントだけが 必要です。SLP フレームワークでは、UA がサービス要求を SA にマルチキャストすることを許可しています。SA は、UA に対して応答をユニキャストします。たとえば、UA がサービス要求メッセージを送信すると、SA はサービス応答メッセージを返します。サービス応答には、クライアントの要求と一致するサービスの場所が含まれています。属性やサービスタイプに関する要求や応答も可能です。詳細は、第 11 章SLP (リファレンス)を参照してください。

図 7–1 SLP の基本的なエージェントとプロセス

次の図は、フレームワークに DA が配置された場合の、SLP アーキテクチャーを実装する基本的なエージェントとプロセスを示しています。

図 7–2 DA を使って実装される SLP アーキテクチャーのエージェントとプロセス

DA を配置すると、ネットワークにはより少ないメッセージが送られるので、UA は情報をすばやく受け取ることができます。DA は、ネットワークのサイズが増大する場合やマルチキャストルーティングがサポートされていない場合に必要です。DA は登録されたサービス通知のキャッシュの役割を果たします。SA は DA に対して、通知するすべてのサービスを一覧表示した登録メッセージ (SrvReg) を送り、その応答として確認応答 (SrvAck) を受け取ります。サービス通知は DA によって更新されるか、通知に設定された有効期限に従って期限切れになります。UA が DA を検出すると、UA は要求を SA にマルチキャストするのではなく、DA にユニキャストします。

Solaris SLP メッセージの詳細は、第 11 章SLP (リファレンス)を参照してください。

SLP の実装

Solaris SLP の実装では、表 7–1 にある SLP の SA、UA、DA、SA サーバー、スコープなどのアーキテクチャーコンポーネントが一部は slpd に、一部はアプリケーションプロセスに割り当てられます。SLP デーモン (slpd) は、特定のオフホストの SLP 相互作用を構成して、次のことを実行します。

• ネットワーク上のすべての DA に対し、ディレクトリエージェントの受動的検出と能動的検出を使用する

• ローカルホスト上の UA と SA が使用するために DA の更新テーブルを保持する

• レガシーサービス通知に対してプロキシ SA サーバーとして機能する (プロキシ登録)

net.slpisDA プロパティーを設定し、slpd が DA として機能するように構成することもできます。第 9 章SLP の管理 (手順)を参照してください。

SLP デーモンの詳細は、slpd(1M) のマニュアルページを参照してください。

slpd の他に、C/C++ クライアントライブラリと Java クライアントライブラリ (libslp.so および slp.jar) が、UA クライアントと SA クライアントに SLP のフレームワークへのアクセス権を提供します。クライアントライブラリは、次の機能を提供します。

• サービス通知の登録と登録解除が可能なネットワークサービスを提供するソフトウェア

• サービス通知にクエリーを発行することによってサービスを要求できるクライアントソフトウェア

• 登録と要求に使用できる SLP スコープのリスト

slpd とクライアントライブラリ (前述のサービスを提供する) 間のプロセス間通信を可能にするには、特別な構成は必要ありません。ただし、ライブラリが機能するように、先に slpd プロセスを実行してからクライアントライブラリをロードする必要があります。

次の図で、サービスプロバイダプログラム内の SLP クライアントライブラリは、SA の機能を使用します。サービスプロバイダプログラムは SLP クライアントライブラリを使用して、サービスを slpd に登録または登録解除します。サービスクライアントプログラムの SLP クライアントライブラリは、UA の機能を使用します。サービスクライアントプログラムは SLP クライアントライブラリを使用して、要求を出します。SLP クライアントライブラリは、SA に要求をマルチキャストするか、DA に要求をユニキャストします。この通信はアプリケーションから見て透過です。ただし、ユニキャスト方式の要求発行はより高速になります。クライアントライブラリの動作は、SLP のさまざまな構成プロパティーの設定によって影響を受けます。詳細は、第 9 章SLP の管理 (手順)を参照してください。slpd プロセスは、マルチキャスト要求への応答、DA への登録など、SA の全機能を処理します。

図 7–3 SLP の実装

SLP の参考資料

SLP の詳細は、次の文書を参照してください。

• Kempf、James、Pete St. Pierre 著、『Service Location Protocol for Enterprise Networks』、John Wiley & Sons、Inc. (ISBN 番号: 0–471–31587–7)。

• 『Authentication Management Infrastructure Administration Guide』(Part No: 805–1139–03)。

• Guttman、Erik、Charles Perkins、John Veizades、Michael Day 著、『Service Location Protocol, Version 2, RFC 2608』、Internet Engineering Task Force (IETF) 。[http://www.ietf.org/rfc/rfc2608.txt ]

• Kempf、James、Erik Guttman 著、『An API for Service Location, RFC 2614』、Internet Engineering Task Force (IETF) 。[http://www.ietf.org/rfc/rfc2614.txt]

第 8 章 SLP の計画と有効化 (手順)

この章では、SLP の計画と有効化について説明します。次の節では、SLP の構成と SLP を有効にするためのプロセスを取り上げています。

• 「SLP 構成の検討事項」

• 「snoop を使用して SLP 動作を監視する」

SLP 構成の検討事項

SLP デーモンはデフォルトのプロパティーで構成済みです。デフォルトの設定で正しく動作する場合、SLP の配置において、ほとんど管理は必要ありません。

ただし場合によっては、デフォルトの SLP プロパティーを変更して、SLP のネットワーク動作を調整することや各種の SLP 機能を有効にすることが必要になります。たとえば、いくつかの構成を変更して、SLP のロギングを有効にすることができます。SLP のログ情報と snoop トレースの情報によって、追加の構成が必要かどうかを判断できます。

SLP 構成プロパティーは、/etc/inet ディレクトリ内の slp.conf ファイルにあります。デフォルトのプロパティー設定を変更する場合は、第 9 章SLP の管理 (手順)の該当する手順を参照してください。

SLP 構成プロパティーの設定を変更する前に、ネットワーク管理で大切な次のことがらを検討してください。

• 動作しているネットワーク技術の種類

• ネットワーク技術が円滑に処理できるトラフィック量

• ネットワークで使用できるサービスの数と種類

• ネットワーク上のユーザー数、ユーザーが必要とするサービス、もっとも頻繁にアクセスするサービスに関係するユーザーの場所

再構成の判断

SLP 対応の snoop ユーティリティーと SLP ログユーティリティーを使用して、再構成が必要かどうかや、変更する必要があるプロパティーを判断できます。たとえば、次の目的のために特定のプロパティーを再構成する場合があります。

• 各種の待ち時間および帯域幅の性質が混在するネットワークメディアを調整する

• ネットワークの障害または計画されていないパーティション分割から回復させる

• DA を追加して SLP マルチキャストの急増を軽減する

• 新規のスコープを実装して、もっとも頻繁にアクセスするサービスにユーザーを編成する

snoop を使用して SLP 動作を監視する

snoop ユーティリティーは受動的に機能する管理ツールで、ネットワークのトラフィック情報を提供します。ユーティリティー自身が発するトラフィックは最小限で、ネットワーク上のすべての動作を監視できます。

snoop ユーティリティーは、実際の SLP メッセージトラフィックのトレースを行います。たとえば、snoop に slp コマンド行引数を付けて実行すると、登録および登録解除の SLP トレース情報が表示されます。このトレース情報を使用して、登録されているサービスの種類および登録動作の量をチェックできるので、ネットワークの負荷を測定できます。

snoop ユーティリティーは、SLP ホスト間のトラフィックフローの監視にも役立ちます。snoop に slp コマンド行引数を付けて実行し、次の種類の SLP 動作を監視することで、ネットワークまたはエージェントの再構成が必要かどうかを判断できます。

• 特定の DA を使用しているホスト数。この情報により、負荷を均等にするために DA をさらに追加して配置するかどうかを判断できます。

• 特定の DA を使用しているホスト数。この情報により、特定のホストに新規または別のスコープを構成すべきかどうかを判断できます。

• UA がタイムアウトを要求しているか、あるいは DA の確認応答が遅いかどうか。UA のタイムアウトや再伝送を監視することで、DA が過負荷になっているかどうかを判断できます。DA が SA に登録の確認応答を送るのに数秒以上かかっているかどうかも確認できます。この情報により、必要に応じて、DA を追加したりスコープの構成を変更したりして、DA にかかるネットワーク負荷を調整します。

snoop に -V (詳細) コマンド行引数を付けて実行すると、登録の有効期限や SrvReg の新規フラグの値を得ることができるので、再登録の数を削減すべきかどうかを判断できます。

snoop を使用して、次のような別の種類の SLP トラフィックをトレースすることもできます。

• UA クライアントと DA 間のトラフィック

• UA クライアントのマルチキャストとそれに対する SA の応答との間のトラフィック

snoop の詳細は、snoop(1m) のマニュアルページを参照してください。

トラフィックおよび輻輳の統計情報を表示するには、netstat コマンドを snoop と併せて使用します。netstat の詳細は、netstat(1M) のマニュアルページを参照してください。

snoop を使用して SLP トレースを実行する方法

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. snoop に slp コマンド行引数を付けて実行します。

   Brief Mode: # snoop slp

   snoop をデフォルトの簡易モードで実行すると、進行中の出力が画面に表示されます。SLP メッセージは SLP トレースあたり 1 行に収まるように切り捨てられます。

   Verbose Mode: # snoop -v slp

   snoop を「詳細」モードで実行すると、進行中の出力がすべて画面に表示されます。出力される情報は次のとおりです。

   • サービス URL の完全なアドレス

   • すべてのサービス属性

   • 登録の有効期限

   • すべてのセキュリティーパラメータとフラグ (存在する場合)

   ---

   注 –

   slp コマンド行引数をほかの snoop オプションとともに使用できます。

   ---

snoop slp トレースの分析

次の例では、slpd は slphost1 上で SA サーバーとしてデフォルトモードで動作しています。SLP デーモンは、slphost2 をエコーサーバーとして初期化して登録しています。その後、snoop slp プロセスが slphost1 上で呼び出されます。

トレース結果を説明しやすくするために、次の snoop からの出力結果にトレース行番号を付けています。

(1) slphost1 -> 239.255.255.253 SLP V@ SrvRqst [24487] service:directory-agent []
(2) slphost2 -> slphost1 SLP V2 DAAdvert [24487] service:directory-agent://129
(3) slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent []
(4) slphost1 -> 239.255.255.253 SLP V2 SrvRqst [24487] service:directory-agent []
(5) slphost1 -> slphost2 SLP V2 SrvReg [24488/tcp]service:echo.sun:tcp://slphost1:
(6) slphost2 -> slphost1 SLP V2 SrvAck [24488/tcp] ok
(7) slphost1 -> slphost2 SLP V2 SrvDereg [24489/tcp] service:echo.sun:tcp://slphost1:
(8) slphost2 -> slphost1 SLP V2 SrvAck [24489/tcp] ok

1. slphost1 上の slpd が、ディレクトリエージェントを探すために SLP マルチキャストグループアドレスにマルチキャストして、ディレクトリエージェントを能動検出していることを示しています。能動検出に対するメッセージ番号 (24487) は、トレース表示では角括弧内に示されます。

2. トレース 1 からの能動検出要求 24487 に対し、ホスト slphost2 上で DA として動作している slpd が応答したことを示します。slphost2 からのサービス URL は 1 行に収まるように切り捨てられています。トレース 1 および 2 のメッセージ番号が一致していることからわかるように、DA はマルチキャストディレクトリエージェント検出メッセージに応答して、DA 通知を送っています。

3. 追加の DA に対する slphost1 上の UA からのマルチキャストを示します。slphost2 はすでに要求に応答しているため、ふたたび応答することはなく、他のどの DA も応答しません。

4. 前の行で示したマルチキャストを繰り返しています。

5. slphost1 上の slpd は、SA クライアントが作成した登録をホスト slphost2 上の DA に転送します。エコーサーバーに対するユニキャストサービス登録 (SrvReg) が、slphost1 によって slphost2 上の DA に行われています。

6. slphost2 が slphost1 の SrvReg に対してサービス確認応答 (SrvAck) で応答していることを表し、登録が完了したことを示しています。

   SA クライアントを稼働しているエコーサーバーと slphost1 上の SLP デーモンとの間のトラフィックは、snoop トレースでは表示されません。表示されないのは、snoop 動作がネットワークループバック上で実行されているからです。

7. slphost1 上のエコーサーバーが、エコーサービス通知の登録を解除します。slphost1 上の SLP デーモンは、登録解除を slphost2 上の DA に転送します。

8. slphost2 が slphost1 に対してサービス確認応答 (SrvAck) で応答していることを表し、登録解除が完了したことを示しています。

   トレース行 5、6、7、8 のメッセージ番号に追加されている /tcp パラメータは、メッセージ交換が TCP で発生したことを示しています。

次に進む手順

SLP トラフィックを監視後、snoop トレースから集められた情報を使用して、SLP デフォルトの再構成が必要かどうかを判断できます。SLP プロパティー値の設定については、第 9 章SLP の管理 (手順)を参照してください。SLP メッセージとサービス登録については、第 11 章SLP (リファレンス)を参照してください。

第 9 章 SLP の管理 (手順)

この章では、SLP のエージェントとプロセスを構成するための情報と作業手順について説明します。

• 「SLP プロパティーの構成」

• 「DA 通知と検出頻度の変更」

• 「異なるネットワーク媒体、トポロジ、または構成の調整」

• 「SLP 検出要求のタイムアウトの変更」

• 「スコープの配置」

• 「DA の配置」

• 「SLP とマルチホーム」

SLP プロパティーの構成

SLP 構成プロパティーは、ネットワークの相互作用、SLP エージェントの特性、状態、およびログを制御します。ほとんどの場合、これらのプロパティーのデフォルトの構成は変更する必要がありません。ただし、ネットワークの媒体またはトポロジが変更されて、次のことを行うためには、この章の手順を使用します。

• ネットワークの待ち時間を補正する

• ネットワークの輻輳を軽減する

• エージェントの追加、または IP アドレスの再割り当てを行う

• SLP ログを起動する

SLP 構成ファイル /etc/inet/slp.conf を編集すると、次の表に示す処理を行うことができます。

SLP 構成ファイルの基本要素

/etc/inet/slp.conf ファイルは、SLP デーモンを再起動するたびにすべての SLP 動作を定義して起動します。構成ファイルは次の要素から成ります。

• 構成プロパティー

• コメント行と注釈

設定プロパティー

net.slp.isDA や net.slp.DAHeartBeat などのすべての基本的な SLP プロパティーは、次の書式で名前が付けられています。

net.slp.<keyword>

SLP の動作は、slp.conf ファイル内のプロパティーの値またはプロパティーの組み合わせによって定義されます。プロパティーは、SLP 構成ファイル内でキーと値の対で構成されています。次の例に示すように、キーと値の対は、プロパティー名とその設定値で構成されています。

<property name>=<value>

各プロパティーのキーはプロパティー名です。値はプロパティーに、数値 (間隔または時間)、真偽の状態、または文字列値のパラメータを設定します。プロパティーの値は次のデータ型の 1 つで構成されます。

• 真偽設定 (ブール型)

• 整数

• 整数のリスト

• 文字列

• 文字列のリスト

定義した値が許可されていない場合は、そのプロパティー名のデフォルト値が使用されます。さらに、syslog を使用してエラーメッセージが記録されます。

コメント行と注釈

slp.conf ファイルにコメントを追加して、その行の性質および機能を説明できます。コメント行はファイルに任意に書き込めるので、管理する上で役立ちます。

構成ファイル内の設定には、大文字と小文字の区別がありません。詳細は、 Guttman、Erik、James Kempf、Charles Perkins 著、 Internet Engineering Task Force (IETF) 発行の『Service Templates and service: scheme RFC 2609』を参照してください。[ http://www.ietf.org/rfc/rfc2609.txt]

SLP 構成の変更方法

SLP 構成ファイルのプロパティー設定を変更するには、次の手順を実行します。SLP を使用できるクライアントまたはサービスソフトウェアは、SLP API を使用して、SLP 構成も変更できます。API については、Internet Engineering Task Force (IETF) 発行の『An API for Service Location, RFC 2614』を参照してください。[http://www.ietf.org/rfc/rfc2614.txt ]

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. 必要に応じて、/etc/inet/slp.conf ファイルのプロパティー設定を編集します。

   SLP プロパティーの設定については、「設定プロパティー」を参照してください。slp.conf プロパティーを変更する別の例については、後述の各節を参照してください。slp.conf(4) のマニュアルページを参照してください。

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

   ---

   注 –

   slpd を停止または起動するとき、SLP デーモンは構成ファイルから情報を取得します。

   ---

例 9–1 slpd が DA サーバーとして動作するように設定する

slpd.conf ファイルの net.slp.isDA プロパティーに Trueを設定して、slpd が DA サーバーとして動作するように SA サーバーのデフォルトを変更できます。

net.slp.isDA=True

各領域で、各種のプロパティーが構成の異なる場合を制御します。以降の各節では、SLP 構成で使用するデフォルトのプロパティー設定を変更するさまざまなシナリオについて説明します。

DA 通知と検出頻度の変更

次のような場合は、DA 通知と検出要求のタイミングを制御するプロパティーを変更できます。

• SA または UA が slp.conf ファイルの net.slp.DAAddresses プロパティーから静的に DA 構成情報を取得するように設定する場合は、DA 検出を無効にできます。

• ネットワークが頻繁にパーティション分割を行う場合は、受動的な通知および定期的な能動的検出の頻度を変更できます。

• UA と SA クライアントがダイアルアップ接続の一方の側で DA にアクセスしている場合は、DA のハートビート頻度と能動的検出の間隔を減らすことで、ダイアルアップ回線の起動回数を少なくできます。

• ネットワークが輻輳している場合は、マルチキャストを制限できます。

この節の手順では、次のプロパティーを変更する方法について説明します。

UA と SA を静的に構成された DA に限定する

UA と SA が slp.conf ファイル内の静的な構成情報から DA アドレスだけを取得するように制限することが必要な場合があります。次の手順では、slpd が net.slp.DAAddresses プロパティーから DA 情報だけを取得するように 2 つのプロパティーを変更できます。

UA と SA を静的に構成された DA に限定する方法

次の手順に従って、net.slp.passiveDADetection および net.slp.DAActiveDiscoveryInterval プロパティーを変更します。

この手順は、静的な構成を使用するように制限されている UA と SA を実行するホストにだけ使用してください。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slp.conf ファイル内の net.slp.passiveDADetection プロパティーに False を設定して、受動的検出を無効にします。この設定により、slpd は非要請 DA 通知を無視します。

   net.slp.passiveDADetection=False

5. net.slp.DAActiveDiscoveryInterval に -1 を設定して、初期および定期の能動的検出を無効にします。

   net.slp.DAActiveDiscoveryInterval=-1

6. 変更を保存し、ファイルを閉じます。

7. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

ダイアルアップネットワークに対する DA 検出の構成

UA または SA がダイアルアップネットワークによって DA から切り離されている場合は、DA 検出を構成して、検出要求と DA 通知の数を削減するか、完全になくすことができます。ダイアルアップネットワークでは、通常起動時に課金されます。余分な通話を最小限に抑えることにより、ダイアルアップネットワークの使用コストを削減できます。

「UA と SA を静的に構成された DA に限定する」で説明している方法で、DA 検出を完全に無効にすることができます。

ダイアルアップネットワークに対する DA 検出の構成方法

次の手順に従って、DA ハートビートの期間と能動的検出の間隔を長くすることで、非要請 DA 通知と能動的検出を削減できます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.DAHeartbeat プロパティーの値を大きくします。

   net.slp.DAHeartbeat=value

   value

   DA 通知の受動的ハートビートに対して秒数を設定する、32 ビットの整数

   デフォルト値は、10800 秒 (3 時間) です

   値の範囲は、2000 から 259200000 秒です

   たとえば、DA を実行しているホストに対して、DA のハートビートを約 18 時間に設定できます。

   net.slp.DAHeartbeat=65535

5. slpd.conf ファイル内の net.slp.DAActiveDiscoveryInterval プロパティーの値を大きくします。

   net.slp.DAActiveDiscoveryInterval value

   value

   DA の能動的検出クエリーに対して秒数を設定する、32 ビットの整数

   デフォルトの値は、900 秒 (15 分) です

   値の範囲は、300 から 10800 秒です

   たとえば、UA と SA を実行しているホストに対して、DA の能動的検出の間隔を 18 時間に設定できます。

   net.slp.DAActiveDiscoveryInterval=65535

6. 変更を保存し、ファイルを閉じます。

7. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

頻繁なパーティション分割に対する DA のハートビートの構成

スコープをサポートするすべての DA に登録するには、SA が必要です。DA は、slpd が能動的検出を行なったあとで現れることがあります。DA が slpd スコープをサポートする場合、SLP デーモンはホスト上のすべての通知を DA に登録します。

slpd が DA を検出する 1 つの方法は、起動時に DA が送り出す初期の非要請通知を使用します。SLP デーモンは定期的な非要請通知 (ハートビート) を使用して、DA がまだアクティブであるかどうかを判断します。ハートビートが出現しない場合、SLP デーモンは自分が使用する DA を削除し、これを UA に申し出ます。

最後に、DA にシャットダウン要求が出されると、DA は特別な DA 通知を転送して、受信中の SA サービスに DA がサービスから抜け出すことを知らせます。SLP デーモンもこの特別な通知を使用して、キャッシュからアクティブでない DA を削除します。

ネットワークが頻繁にパーティション分割を行い、SA の期限が長い場合、ハートビートの通知を受けなければ、slpd はパーティションの分割中に DA をキャッシュから削除できます。ハートビートの頻度を減らすことにより、使用中止になった DA がパーティションの修正後にキャッシュに復元されるまでの遅延時間を縮小できます。

頻繁なパーティション分割に対して DA のハートビートを構成する方法

次の手順に従って、net.slp.DAHeartBeat プロパティーを変更し、DA のハートビート期間を短くします。

DA 検出が完全に無効になっている場合、UA と SA を実行しているホストが正しい DA にアクセスするように、そのホストの slp.conf の net.slp.DAAddresses プロパティーを設定する必要があります。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. net.slp.DAHeartBeat の値を 1 時間 (3600 秒) に短縮します。デフォルトでは、DA のハートビート期間は 3 時間 (10800 秒) に設定されています。

   net.slp.DAHeartBeat=3600

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

ネットワーク輻輳の軽減

ネットワークが非常に混雑している場合、マルチキャストの量を制限できます。ネットワークに DA を配置していない場合は、DA を配置すると SLP 関連のマルチキャストの量を大幅に削減できます。

ただし、DA の配置後でも DA 検出のためのマルチキャストは必要です。DA 検出に必要なマルチキャストの量は、「ダイアルアップネットワークに対する DA 検出の構成方法」で説明している方法で削減できます。「UA と SA を静的に構成された DA に限定する」で説明している方法で、DA 検出のためのマルチキャストを完全になくすことができます。

異なるネットワーク媒体、トポロジ、または構成の調整

この節では、次のプロパティーを変更して SLP のパフォーマンスを調整する場合の可能なシナリオについて説明します。

SA 再登録の削減

SA は、期限が切れる前に定期的にサービス通知を更新する必要があります。DA が多くの UA および SA から非常に重い負荷を受けている場合は、頻繁な更新により DA が過負荷になることがあります。DA が過負荷になると、UA の要求がタイムアウトして欠落します。UA 要求のタイムアウトには多くの原因が考えられます。DA の過負荷が問題であると判断する前に、snoop トレースを使ってサービス登録に登録されているサービス通知の有効期限を確認してください。有効期限が短く、再登録が頻繁に発生している場合は、再登録が頻繁すぎることがタイムアウトの原因と考えられます。

サービス登録は、FRESH フラグが設定されていなければ再登録になります。サービス登録メッセージについては、第 11 章SLP (リファレンス)を参照してください。

SA 再登録を削減する方法

次の手順に従って、SA の最小更新間隔を長くすることで、再登録回数を削減します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. net.slp.DAAttributes プロパティーの min-refresh-interval 属性の値を大きくします。

   デフォルトの最短再登録期間はゼロ (0) です。デフォルトのゼロである場合、SA はいつでも自由に再登録できます。次の例では、間隔は 3600 秒 (1 時間) に増やしています。

   net.slp.DAAttributes(min-refresh-interval=3600)

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

マルチキャストの有効期限プロパティーの構成

マルチキャストの有効期限プロパティー (net.slp.multicastTTL) によって、マルチキャストパケットがイントラネット内で伝達される範囲が決まります。マルチキャスト TTL は net.slp.multicastTTL プロパティーを 1 から 255 までの整数に設定することにより構成されます。マルチキャスト TTL のデフォルト値は 255 で、これは理論的にはパケット経路が無制限であることを意味します。しかし、TTL を 255 とすると、マルチキャストパケットがイントラネットを超えて管理ドメインの端にある境界ルーターまで進む原因になります。マルチキャストパケットがインターネットのマルチキャストバックボーンまたは ISP に漏れないようにするには、境界ルーター上のマルチキャストが正しく構成されている必要があります。

マルチキャスト TTL のスコープ設定は、TTL 比較が行われることを除いて、標準的な IP の TTL と似ています。マルチキャストを実行できるルーター上の各インタフェースには、TTL 値が割り当てられています。マルチキャストパケットが着信すると、ルーターはパケットの TTL をインタフェースの TTL と比較します。パケットの TTL がインタフェースの TTL 値と同じかそれより大きい場合は、標準的な IP の TTL の場合と同じように、パケットの TTL を 1 減らします。TTL がゼロになると、そのパケットは破棄されます。SLP マルチキャストに TTL スコープを使用する場合、パケットをイントラネットの特定のサブセクションに限定するために、ルーターが正しく構成されている必要があります。

マルチキャストの有効期限プロパティーの構成方法

次の手順に従って、net.slp.multicastTTL プロパティーを設定し直します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.multicastTTL プロパティーを変更します。

   net.slp.multicastTTL=value

   value

   マルチキャスト TTL を定義する 255 以下の正の整数

   ---

   注 –

   TTL 値を減らしてマルチキャストの伝達範囲を縮小することができます。TTL の値が 1 の場合、パケットはそのサブネットに限定されます。TTL の値が 32 の場合は、パケットはそのサイトに限定されます。「サイト」は、マルチキャスト TTL について記述されている RFC 1075 では定義されていません。32 以上の値は、インターネット上の論理的な経路を指すので使用しないでください。32 未満の値は、各ルーターが TTL で正しく構成されていれば、マルチキャストをアクセス可能なサブネットのセットに限定するために使用できます。

   ---

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

パケットサイズの構成

SLP のデフォルトのパケットサイズは 1400 バイトです。ほとんどのローカルエリアネットワークにはこのサイズで十分です。無線ネットワークまたは広域ネットワークの場合は、メッセージの断片化を防いだりネットワークのトラフィックを削減したりするために、パケットサイズを縮小できます。より大きなパケットを持つローカルエリアネットワークの場合は、パケットサイズを大きくするとパフォーマンスが向上します。ネットワークの最小パケットサイズを確認して、パケットサイズの縮小が必要かどうかを判断できます。ネットワーク媒体のパケットサイズがより小さい場合は、それに合わせて net.slp.MTU の値を小さくできます。

ネットワーク媒体のパケットサイズがより大きい場合は、それに合わせて値を大きくできます。ただし、SA からのサービス通知または UA からのクエリーが頻繁にデフォルトのパケットサイズをオーバーフローするのでなければ、net.slp.MTU の値を変更する必要はありません。snoop を使用して、UA 要求がデフォルトのパケットサイズを頻繁にオーバーフローし、UDP ではなく TCP を使用するためにロールオーバーしているかどうかを判断できます。

net.slp.MTU プロパティーは、リンク層ヘッダー、IP ヘッダー、UDP または TCP ヘッダー、SLP メッセージを含めた、IP パケットの全体サイズを測定します。

パケットサイズの構成方法

次の手順に従って、net.slp.MTU プロパティーを調整することで、デフォルトのパケットサイズを変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.MTU プロパティーを変更します。

   net.slp.MTU=value

   value

   ネットワークのパケットサイズ (バイト単位) を指定する、16 ビットの整数

   デフォルト値は、1400

   値の範囲は、128 から 8192

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

ブロードキャスト専用ルーティングの構成

SLP は、DA が存在しない場合のサービス検出や DA 検出を、マルチキャストを使って行うように設計されています。使用するネットワークが、マルチキャストルーティングを配置しない場合は、net.slp.isBroadcastOnly プロパティーに True を設定することで、SLP がブロードキャストを使用するように構成できます。

マルチキャストと異なり、ブロードキャストパケットはデフォルトでサブネットを越えて伝達しません。このため、マルチキャストを行わないネットワークでは、DA を使用しないサービス検出は、単一のサブネット上でしか機能しません。さらに、ブロードキャストが使用されているネットワークに DA およびスコープを配置する場合は、特別な考慮が求められます。マルチホームホスト上の DA は、マルチキャストが使用できない複数のサブネット間でサービス検出をブリッジできます。マルチホームホスト上の DA の配置については、「DA の配置とスコープ名の割り当て」を参照してください。

ブロードキャスト専用ルーティングの構成方法

次の手順に従って、net.slp.isBroadcastOnly プロパティーを True に変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.isBroadcastOnly プロパティーを True に変更します。

   net.slp.isBroadcastOnly=True

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

SLP 検出要求のタイムアウトの変更

SLP 検出要求のタイムアウトを変更する必要があるのは、次の 2 つの場合です。

• SLP エージェントが複数のサブネット、ダイアルアップ回線、または別の WAN によって切り離されている場合は、ネットワークの待ち時間が長く、デフォルトのタイムアウトでは要求や登録を完了できないことがあります。逆に、ネットワークの待ち時間が短い場合は、タイムアウトを短くすることにより、パフォーマンスが向上することがあります。

• トラフィックが多いネットワークまたは衝突率の高いネットワークの場合、SA および UA がメッセージを送る前に待たなければならない最長の時間が不足して、衝突のないトランザクションを確保できない場合があります。

デフォルトのタイムアウトの変更

ネットワークの待ち時間が長いと、UA および SA が要求と登録を行う場合、応答を受け取る前にタイムアウトになる原因になります。複数のサブネット、ダイアルアップ回線、または WAN によって UA が SA から切り離されている場合、または UA と SA の両方が DA から切り離されている場合、待ち時間が問題となることがあります。待ち時間が問題であるかどうかを判断するには、UA および SA の要求と登録でタイムアウトが起こったために SLP 要求が失敗しているかどうかを確認します。ping コマンドを使って実際の待ち時間を測定することもできます。

次の表は、タイムアウトを制御する構成プロパティーを示します。この節で説明する手順で、これらのプロパティーを変更できます。

マルチキャストサービスの検出中または DA の検出中に頻繁にタイムアウトが発生する場合は、net.slp.multicastMaximumWait プロパティーをデフォルト値の 15000 ミリ秒 (15 秒) から増やしてください。最大待ち時間を長くすることにより、待ち時間の長いネットワーク上で要求に対してより長い時間が許可されます。net.slp.multicastMaximumWait プロパティーの値を増やしたあとは、net.slp.multicastTimeouts と net.slp.DADiscoveryTimeouts も変更する必要があります。これらのプロパティーのタイムアウト値の合計が net.slp.multicastMaximumWait 値と等しくなるようにしてください。

デフォルトのタイムアウトの変更方法

次の手順に従って、タイムアウトを制御する SLP プロパティーを変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.multicastMaximumWait プロパティーを変更します。

   net.slp.multicastMaximumWait=value

   value

   net.slp.multicastTimeouts と net.slp.DADiscoveryTimeouts に設定する値の合計値を示す、32 ビットの整数

   デフォルト値は、15000 ミリ秒 (15 秒) です

   値の範囲は、1000 から 60000 ミリ秒です

   たとえば、マルチキャスト要求で 20 秒 (20000 ミリ秒) 必要だと判断したら、net.slp.multicastTimeouts プロパティーと net.slp.DADiscoveryTimeouts プロパティーに一覧表示されている値の合計が 20000 ミリ秒になるように調整します。

   net.slp.multicastMaximumWait=20000 net.slp.multicastTimeouts=2000,5000,6000,7000 net.slp.DADiscoveryTimeouts=3000,3000,6000,8000

5. slpd.conf ファイル内の net.slp.datagramTimeouts プロパティーを必要に応じて変更します。

   net.slp.datagramTimeouts=value

   value

   ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒) を指定する、32 ビット整数のリスト

   デフォルト値は、3000,3000,3000 です

   たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。

   net.slp.datagramTimeouts=2000,5000,6000,7000

   高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。タイムアウトの上限を小さくすることで、SLP 要求を満たすために必要な待ち時間を短縮できます。

6. 変更を保存し、ファイルを閉じます。

7. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

ランダム待ち時間の上限の構成

トラフィックの重いネットワークや衝突率の高いネットワークでは、DA との通信が影響を受けることがあります。衝突率が高い場合、送信エージェントは、UDP データグラムを再転送する必要があります。再転送が発生しているかどうかは、snoop を使用して、SA サーバーとして slpd を実行しているホスト、および DA サーバーとして slpd を実行しているホストのネットワークトラフィックを監視することにより判断できます。SA サーバーとして slpd を実行しているホストから同じサービスについて複数のサービス登録メッセージが snoop トレースに現れる場合は、衝突の問題があると考えられます。

衝突は、ブート時の主要な問題となる場合があります。DA が最初に起動されると、DA は非要請通知を送り出し、SA はそれらの登録に応答します。SLP は、DA 通知を受け取ってから応答するまでにランダムな時間だけ、SA を待たせます。このランダムな待ち時間は、net.slp.randomWaitBound によって制御される最大値を使って均等に分散されます。デフォルトのランダム待ち時間の上限は 1000 ミリ秒 (1 秒) です。

ランダム待ち時間の上限の構成方法

次の手順に従って、slp.conf ファイルの net.slp.RandomWaitBound プロパティーを変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.RandomWaitBound プロパティーを変更します。

   net.slp.RandomWaitBound=value

   value

   DA に接続するまでのランダム待ち時間の計算に使用される上限

   デフォルト値は、1000 ミリ秒 (1 秒) です

   値の範囲は、1000 から 3000 ミリ秒です

   たとえば、ランダム待ち時間を 2000 ミリ秒 (2 秒) に延長できます。

   net.slp.randomWaitBound=2000

   ランダム待ち時間の上限を長くすると、登録で遅延が長くなります。SA は新しく検出された DA をより時間をかけて登録できるので、衝突とタイムアウトを回避することができます。

5. slpd.conf ファイル内の net.slp.datagramTimeouts プロパティーを必要に応じて変更します。

   net.slp.datgramTimeouts=value

   value

   ユニキャストのデータグラム転送を DA に実行するためのタイムアウト (ミリ秒) を指定する、32 ビット整数のリスト

   デフォルト値は、3000,3000,3000 です

   たとえば、頻繁なタイムアウトの発生を回避するために、データグラムのタイムアウトを 20000 ミリ秒に増やすことができます。

   net.slp.datagramTimeouts=2000,5000,6000,7000

   高パフォーマンスのネットワークでは、逆に UDP データグラム転送のマルチキャストまたはユニキャストのタイムアウトの上限を小さくできます。この設定により、SLP 要求を満たす際に、待ち時間を短縮できます。

6. 変更を保存し、ファイルを閉じます。

7. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

スコープの配置

スコープを使用すると、論理的、物理的、および管理上のユーザーのグループによるサービスへの対応が可能です。スコープを使用することで、サービス通知へのアクセスの管理が可能になります。

net.slp.useScopes プロパティーを使用すると、スコープを作成できます。たとえば、次のように構成すると、ホスト上の /etc/inet/slp.conf ファイルに、newscope という名前の新規のスコープが追加されます。

net.slp.useScopes=newscope

たとえば、プリンタや FAX などのネットワーク接続されたオフィス機器の小部屋が、会社の 6号棟 2 階の南側の廊下の突き当たりにあるとします。これらのオフィス機器は 2 階のすべてのユーザーに提供されている場合や、使用が特定の部署のメンバーに限定する場合があります。スコープはこれらの機器に対するサービス通知へのアクセスに対応する手段を提供します。

オフィス機器をマーケティング部専用にすると、mktg という名前のスコープを作成することができます。別の部署に所属しているオフィス機器は、別のスコープ名で構成できます。

また、部署が分散している場合もあります。たとえば、機械工学部門と CAD/CAM 部門が 1 階と 2 階に分かれているとします。この場合でも、両者に同じスコープを割り当てることにより、1 階と 2 階にあるホストに 2 階のマシンを提供できます。ネットワークとユーザーに都合よく動作するように、スコープはどのように配置してもかまいません。

特定のスコープを持つ UA は、別のスコープで通知されたサービスを実際に使用できないわけではありません。スコープの構成は、UA が検出するサービス通知を制御するだけです。サービス自体が、なんらかのアクセス制御の制限を行う必要があります。

スコープを構成する場合

SLP はスコープ構成をまったく行わなくても十分機能します。Solaris オペレーティング環境では、SLP のデフォルトのスコープは default です。構成されているスコープがない場合は、default がすべての SLP メッセージのスコープになります。

次の環境のどれかに当てはまれば、スコープを構成できます。

• サポートしている組織が、所属メンバーに対するサービス通知アクセスを制限する場合。

• サポートしている組織が、特定のユーザーが特定領域のサービスにアクセスするように物理的に配置されている場合。

• ユーザーが認識できるサービス通知を分割する必要がある場合。

最初の場合の例を「ダイアルアップネットワークに対する DA 検出の構成」に挙げました。2 番目の例は、組織が 2 つの建物に分かれていて、1 つの建物のユーザーはその建物のローカルサービスにアクセスするようにする場合です。ビルディング 1 のユーザーはスコープ B1 を使用して、ビルディング 2 のユーザーはスコープ B2 を使って構成できます。

スコープを構成する場合の検討事項

slpd.conf ファイル内の net.slp.useScopes プロパティーを変更する場合は、ホスト上のすべてのエージェントにスコープを構成します。ホストが SA を実行している場合や DA として機能している場合に、その SA と DA に default 以外のスコープを構成するには、このプロパティーを構成する必要があります。UA だけがマシン上で動作し、UA が、default 以外のスコープをサポートしている SA と DA を検出する必要がある場合は、UA が使用するスコープを制限するのでなければ、プロパティーを構成する必要はありません。プロパティーを構成しない場合、UA は、slpd を通じて、使用可能な DA とスコープを自動的に検出します。SLP デーモンは、能動的および受動的 DA 検出を使用して DA を見つけるか、DA が動作していない場合は SA 検出を使用して DA を見つけます。プロパティーを構成する場合、UA は構成されたスコープを使用するだけで、構成されたスコープを破棄することはありません。

スコープを構成することを決定した場合は、ネットワーク内のすべての SA にスコープが構成されていることが確実でないかぎり、構成されたスコープのリスト上で default スコープを維持することを検討してください。構成されていない SA があると、構成されたスコープを持つ UA はそれらの SA を見つけることができません。これは、構成されていない SA が自動的に default スコープを持つのに対し、UA は構成されたスコープを持つためです。

net.slp.DAAddresses プロパティーを設定して DA も構成しようとする場合は、構成される DA によってサポートされるスコープが、net.slp.useScopes プロパティーで構成したスコープと同じであることを確認してください。スコープが同じでない場合は、再起動時に slpd がエラーメッセージを出力します。

スコープの構成方法

次の手順に従って、スコープ名を slp.conf ファイルの net.slp.useScopes プロパティーに追加します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.useScopes プロパティーを変更します。

   net.slp.useScopes=<scope names>

   scope names

   文字列のリストで、DA または SA が要求時に使用を許されるスコープを示すか、DA がサポートする必要があるスコープを示す

   デフォルトの値は、SA と DA の場合は Default、UA の場合は未設定

   ---

   注 –

   スコープ名は、次の文法上のガイドラインに従って構成します。

   • 大文字または小文字の英数字

   • 句読点 (''、\、!、<、=、>、および ~ を除く)

   • 名前の一部と考えられるスペース

   • 非 ASCII 文字

     ASCII でない文字をエスケープするには、バックスラッシュを使用します。たとえば、UTF-8 コード体系では、フランス語の aigue アクセントのある文字 e を表すために、16 進コード 0xc3a9 を使用します。プラットフォームが UTF-8 をサポートしていない場合は、UTF-8 の 16 進コード \c3\a9 をエスケープシーケンスとして使用します。

   ---

   たとえば、bldg6 で eng および mktg グループ用のスコープを指定するには、net.slp.useScopes 行を次のように変更します。

   net.slp.useScopes=eng,mktg,bldg6

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

DA の配置

この節では、SLP を実行しているネットワークでの計画的な DA の配置について説明します。

配置された DA または構成されたスコープがなくても、基本のエージェントである UA と SA だけで SLP は十分機能します。特定の構成を持たないすべてのエージェントは自動的に default スコープを使用します。DA はサービス通知のキャッシュとして機能します。DA を配置すると、ネットワークに送られるメッセージ数が削減されるため、メッセージ応答の受け取りに必要な時間も短縮されます。これにより、SLP をより大規模なネットワークに対応させることができます。

SLP DA を配置する理由

DA を配置する主な目的は、サービス検出によって生じるマルチキャストトラフィックの量とユニキャスト応答の収集に関係する遅延を削減することです。多くの UA および SA を持つ大規模なネットワークでは、サービス検出によって生じるマルチキャストの量が非常に大きくなるので、ネットワークのパフォーマンスが下がります。1 つまたは複数の DA を配置すると、UA はサービスについて DA にユニキャストし、SA はユニキャストを使用して DA に登録する必要があります。DA を使用したネットワークでは、SLP 登録されたマルチキャストは、能動的および受動的 DA 検出のマルチキャストだけです。

SA は、マルチキャストのサービス要求を受け取るのではなく、共通のスコープのセット内で検出した任意の DA に自動的に登録します。ただし、DA がサポートしていないスコープ内のマルチキャスト要求には、SA が直接応答します。

UA から出されたサービス要求は、UA のスコープ内に DA が配置されている場合 は、ネットワーク上へのマルチキャストではなく DA に対するユニキャストです。そのため、UA のスコープ内に DA を配置すると、マルチキャストが削減されます。通常の UA 要求を行うマルチキャストをなくすことにより、クエリー応答の受け取りに必要な時間が秒単位からミリ秒単位に大幅に縮小します。

DA は SA および UA の動作の中心として機能します。スコープの集合に対して 1 つまたは複数の DA を配置することにより、SLP の動作を監視するための集中的なポイントが提供されます。DA ログを起動することにより、ネットワークに散在している複数の SA から取り寄せたログをチェックするよりも、登録および要求の監視が容易になります。負荷を均等にする必要に合わせて、1 つまたは複数の特定のスコープに対して DA をいくつでも配置できます。

マルチキャストルーティングが使用できないネットワークでは、SLP がブロードキャストを使用するように構成できます。しかし、ブロードキャストは各ホストにメッセージを処理するように要求するため、非常に効率が悪くなります。また、ブロードキャストは通常、ルーターを超えて伝達されません。この結果、マルチキャストルーティングに対応していないネットワークでは、同じサブネットでしかサービスを検出できません。マルチキャストルーティングに一部しか対応していない場合は、ネットワーク上でサービスを検出する機能に矛盾が生じます。マルチキャストメッセージは DA の検出に使用されます。したがって、マルチキャストルーティングに一部しか対応していない場合は、UA と SA はサービスを SA のスコープ内にある既知の DA に登録することが暗黙の了解になっています。たとえば、UA が DA1 と呼ばれる DA にクエリーを出し、SA がサービスを DA2 に登録している場合、UA はサービスの検出に失敗します。マルチキャストが使用できないネットワーク上の SLP の配置については、「ブロードキャスト専用ルーティングの構成」を参照してください。

サイト全体がマルチキャストルーティングに対応していないネットワークでは、net.slp.DAAdresseses プロパティーを使用して、SLP の UA と SA が DA 位置に関して矛盾のないリストを持つように構成する必要があります。

最後に、Solaris SLPv2 の DA は SLPv1 との相互運用性をサポートしています。SLPv1 相互運用性は、Solaris DA ではデフォルトにより有効になっています。ネットワークにプリンタなどの SLPv1 デバイスが接続されている場合、またはサービス検出で SLPv1 を使用している Novell Netware 5 と相互運用する必要がある場合、DA を配置する必要があります。DA が配置されていないと、Solaris SLP の UA は SLPv1 によって通知されたサービスを見つけることができません。

DA を配置する場合

次の条件のどれかに当てはまる場合は、エンタープライズに DA を配置します。

• snoop で測定した、ネットワーク上での SLP のマルチキャストのトラフィックが帯域幅の 1% を超える。

• UA クライアントがサービス要求のマルチキャスト中に長時間遅延またはタイムアウトする。

• 1 台または複数台のホスト上にある特定のスコープに対して、SLP サービス通知の監視を集中する。

• ネットワークが、サービスを共有する複数のサブネットから構成され、マルチキャストに対応していない。

• ネットワークが前バージョンの SLP (SLPv1) をサポートするデバイスを使用している、または SLP サービス検出で Novell Netware 5 と相互運用したい。

DA を配置する方法

次の手順に従って、slp.conf ファイルの net.slp.isDA プロパティーに True を設定します。

1 台のホストにつき 1 つの DA だけが割り当てられます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.isDA プロパティーに True を設定します。

   net.slp.isDA=True

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

DA を配置する場所

この節は、DA を配置する場所について状況ごとにヒントを示します。

• マルチキャストルーティングが使用できず、DA がサブネット間のサービス検出をブリッジする必要がある場合

  この場合は、インタフェースとサービスを共有するすべてのサブネットを持つホスト上に DA を配置してください。IP パケットがインタフェースの間を経路指定されない場合を除き、net.slp.interfaces 構成プロパティーを設定する必要はありません 。net.slp.interfaces プロパティーの設定については、「SLP に対するマルチホームの構成」を参照してください。

• DA が拡張に備えて配置されており、考慮すべき主要な事柄がエージェントのアクセスの最適化である場合

  UA は通常、DA に対してサービスを大量に要求します。SA がサービスを DA に登録すると、SA は通知を定期的に適切な頻度で更新できます。その結果、UA から DA へのアクセスの方が SA のアクセスよりはるかに頻繁になります。通常、サービス通知の数も要求の数より小さくなります。このため、UA のアクセスに対して DA の配置が最適化されている場合、多くの DA を配置することは効率化をうながします。

• UA のアクセスを最適化するために、ネットワーク上でトポロジ的に UA の近くになるように DA を配置する場合

  UA クライアントと SA クライアントの両方が共有しているスコープを使用して、DA を構成してください。

複数の DA を配置して負荷を均等にする

負荷を均等にする手段として、同じスコープの集合体について複数の DA を配置できます。次の状況のどれかに当てはまれば、DA を配置できます。

• DA に対する UA 要求がタイムアウトしているか、あるいは DA_BUSY_NOW エラーが返っている。

• DA ログが、多くの SLP 要求が欠落していることを示す。

• スコープ内でサービスを共有しているユーザーのネットワークが、複数の建物や物理的なサイトに渡っている。

SLP トラフィックの snoop トレースを行うことによって、どれくらいの UA 要求で DA_BUSY_NOW エラーが返されるかを判断することができます。返される UA 要求の数が多い場合は、DA から物理的およびトポロジ的に離れている建物内の UA は、応答が遅かったり過度にタイムアウトしたりすることがあります。このような場合、建物内の UA クライアントの応答を改善するために、建物ごとに DA を配置できます。

建物間を接続しているリンクは、建物内のローカルエリアネットワークよりも遅いことがあります。ネットワークが複数の建物または物理的なサイトに渡っている場合は、/etc/inet/slp.conf ファイル内の net.slp.DAAddresses プロパティーを特定のホスト名またはアドレスのリストに設定して、指定した DA だけに UA がアクセスするようにします。

特定の DA がサービス登録に対して大量のホストメモリーを消費している場合は、DA がサポートするスコープ数を減らすことによって、SA 登録の数を削減します。登録数の多いスコープを、たとえば 2 つのスコープに分けることができます。次に、片方の DA を別のホストに配置することによって、もう片方のスコープだけをサポートするようにできます。

SLP とマルチホーム

マルチホームサーバーは、複数の IP サブネット上でホストとして機能します。そのようなサーバーに複数のネットワークインタフェースカードが装着されると、ルーターとして機能できます。マルチキャストパケットを含む IP パケットは、このインタフェース間を経路指定されます。場合によっては、インタフェース間の経路指定ができないことがあります。この節では、そのような場合に SLP を構成する方法について説明します。

SLP に対するマルチホームの構成

構成を行わない場合、slpd はデフォルトのネットワークインタフェース上でマルチキャストと UDP/TCP ユニキャストに対して待機しています。ユニキャストルーティングとマルチキャストルーティングがマルチホームマシンのインタフェース間で使用できる場合は、追加の構成を行う必要はありません。追加の構成が必要ないのは、別のインタフェースに到達するマルチキャストパケットがデフォルトで正確に経路指定されているからです。その結果、DA またはほかのサービス通知のマルチキャスト要求は、slpd に届きます。経路指定がなんらかの理由で調整されていない場合は、構成が必要です。

経路指定されていない複数のネットワークインタフェースに対して構成を行う場合

マルチホームマシンの構成が必要と考えられるのは、主に次の場合です。

• ユニキャストルーティングはインタフェース間で使用できるが、マルチキャストルーティングは使用できない。

• ユニキャストルーティングとマルチキャストルーティングの両方がインタフェース間で使用できない。

マルチキャストルーティングがインタフェース間で使用できない場合は、通常、マルチキャストがネットワークに配置されていないことが原因です。この場合は通常、それぞれのサブネット上の DA ベースでないサービス検出および DA 検出にブロードキャストが使用されます。ブロードキャストは、net.slp.isBroadcastOnly プロパティーを True に設定することによって構成します。

経路指定されていない複数のネットワークインタフェースの構成 (作業マップ)

net.slp.interfaces プロパティーの構成

net.slp.interfaces プロパティーが設定されている場合、slpd は、ユニキャストとマルチキャスト/ブロードキャストの SLP 要求を、デフォルトのインタフェース上ではなく、プロパティーに一覧表示されたインタフェース上で待機します。

通常、net.slp.interfaces プロパティーを設定すると同時に、net.slp.isBroadcastOnly プロパティーも設定することでブロードキャストを有効にします。ただし、マルチキャストは配置されているが、この特定のマルチホームホスト上で経路指定されていない場合、マルチキャスト要求は、複数のインタフェースから slpd に到達できます。このような状況は、パケットの経路指定が、別のマルチホームホストまたはインタフェースからサービスを受けるサブネットに接続されているルーターによって制御されている場合に起こります。

この場合、SA サーバーまたは要求を送っている UA は、マルチホームホストの slpd から 2 つの応答を受け取ります。これらの応答はクライアントライブラリによってフィルタにかけられて除かれるので、クライアントには見えません。ただし、この応答は、snoop トレースで見ることができます。

ユニキャストルーティングがオフになっている場合、マルチホームホスト上の SA クライアントによるサービス通知がすべてのサブネットに到達できないことがあります。サービスが到達できない場合、SA クライアントは次のことを実行できます。

• 個々のサブネットにつき 1 つのサービス URL を通知する。

• 特定のサブネットからの要求が到達可能な URL で確実に応答されるようにする。

SA クライアントライブラリには、到達可能な URL が確実に通知されるようにするためのしくみはありません。したがって、到達可能な URL が確実に通知されるようにするには、経路指定のないマルチホームホストを処理できるかどうかにかかわらず、サービスプログラムに任せる必要があります。

ユニキャストルーティングが無効なマルチホームホストにサービスを配置する前に、snoop を使ってサービスが複数のサブネットから出された要求を正確に処理しているかどうかを判断してください。さらに、マルチホームホストに DA を配置することを計画している場合は、「DA の配置とスコープ名の割り当て」を参照してください。

net.slp.interfaces プロパティーの構成方法

次の手順に従って、slp.conf ファイルの net.slp.interfaces プロパティーを変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

2. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

3. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

4. slpd.conf ファイル内の net.slp.interfaces プロパティーを変更します。

   net.slp.interfaces=value

   value

   IPv4 アドレスまたはネットワークインタフェースカードのホスト名のリストで、そこに存在する DA や SA はポート 427 上でマルチキャスト、ユニキャスト UDP、および TCP の各メッセージを待機する必要がある

   たとえば、3 枚のネットワークカードを持ち、マルチキャストルーティングがオフになっているサーバーが、3 つのサブネットに接続されているとします。その 3 つのネットワークインタフェースの IP アドレスは 192.147.142.42、192.147.143.42、および 192.147.144.42 です。サブネットマスクは 255.255.255.0 です。次のプロパティーの設定を行うと、slpd はユニキャストおよびマルチキャストまたはブロードキャストのメッセージについて、3 つすべてのインタフェース上のものに対して待機します。

   net.slp.interfaces=192.147.142.42,192.147.143.42,192.147.144.42

   ---

   注 –

   net.slp.interfaces プロパティーには、IP アドレスまたは解決可能なホスト名を設定できます。

   ---

5. 変更を保存し、ファイルを閉じます。

6. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

マルチホームホスト上のプロキシ通知

複数のインタフェースを持つホストが slpd およびプロキシ登録を使ってサービスを通知する場合は、slpd によって通知されるサービス URL に到達可能なホスト名またはアドレスが含まれている必要があります。インタフェース間でユニキャストルーティングが有効な場合は、すべてのサブネット上のホストは別のサブネット上のホストに到達できます。任意のサブネット上のサービスに対してプロキシ登録も行うことができます。ただし、ユニキャストルーティングが無効な場合は、1 つのサブネット上のサービスクライアントはマルチホームホストを通じて別のサブネット上のサービスに到達することはできません。ただし、これらのクライアントが別のルーターを通じてサービスに到達できる可能性はあります。

たとえば、デフォルトのホスト名が bigguy のホストが、経路指定されていない異なる 3 つのサブネット上に 3 枚のインタフェースカードを持っているとします。これらのサブネット上のホスト名は、IP アドレス 192.147.142.42 を持つ bigguy、IP アドレス 192.147.143.42 を持つ bigguy1、IP アドレス 192.147.144.42 を持つ bigguy2 です。ここで、レガシープリンタ oldprinter がサブネット 143 に接続され、すべてのインタフェース上で待機するために、URL service:printing:lpr://oldprinter/queue1 が net.slp.interfaces で構成されているとします。oldprinter の URL はすべてのインタフェース上でプロキシ通知されます。サブネット 142 と 144 上のマシンは、サービス要求に対する応答でこの URL を受信しますが、oldprinter サービスにアクセスすることはできません。

この問題の解決方法は、マルチホームホスト上ではなく、サブネット 143 だけに接続されたマシン上で動作している slpd を使ってプロキシ通知を行うことです。サブネット 143 上のホストだけがサービス要求に対する応答でこの通知を取得できます。

DA の配置とスコープ名の割り当て

マルチホームホストを持つネットワーク上で DA の配置とスコープ名の割り当てを行う場合は、クライアントがアクセス可能なサービスを確実に取得できるように注意してください。経路指定が無効で net.slp.interfaces プロパティーが構成されている場合は特に注意してください。また、マルチホームマシン上のインタフェース間でユニキャストルーティングが有効な場合は、特別な DA やスコープを構成する必要はありません。これは、DA にキャッシュされている通知が任意のサブネットからアクセス可能なサービスを識別するためです。ただし、ユニキャストルーティングが無効な場合は、DA をうまく配置しないと問題になることがあります。

前述の例で何が問題になりうるかを見るために、bigguy が DA を実行し、すべてのサブネット上のクライアントが同じスコープを持つ場合に何が起こるかを考えてみます。サブネット 143 上の SA はサービス通知を DA に登録します。サブネット 144 上の UA は、サブネット 143 上のホストに到達できなくても、それらのサービス通知を入手できます。

この問題の 1 つの解決方法は、マルチホームホスト上ではなく、各サブネット上で DA を実行することです。この場合は、マルチホームホスト上の net.slp.interfaces プロパティーを、単一のインタフェースホスト名またはアドレスを使って構成するか、構成しないでそのままにし、強制的にデフォルトのインタフェースを使用するようにします。この解決方法の欠点は、通常大規模なマシンであり、DA として高機能であるマルチホームホストを DA に設定できないことです。

もう 1 つの解決方法は、マルチホームホスト上で DA を実行するが、各サブネット上の SA および UA が異なるスコープを持つようにスコープを構成することです。たとえば、前述の場合、142 サブネット上の UA と SA がスコープ scope142 を持つようにスコープを構成することができます。143 サブネット上の UA と SA は、scope143 という別のスコープを持ち、144 サブネット上の UA と SA は scope144 という別のスコープを持つように構成することができます。3 つのインタフェースを持つ bigguy 上の net.slp.interfaces プロパティーを構成して、DA を 3 つのサブネット上の 3 つのスコープに作用させることができます。

経路指定されていない複数のネットワークインタフェースを構成する場合の検討事項

net.slp.interfaces プロパティーを構成すると、マルチホームホスト上の DA がサブネット間のサービス通知をブリッジできるように設定できます。このような構成は、ネットワークでマルチキャストルーティングがオフで、マルチホームホスト上のインタフェース間でユニキャストルーティングが有効な場合に便利です。ユニキャストはインタフェース間を経路指定しているため、サービスが置かれているサブネットと異なるサブネット上のホストは、サービス URL を受信すればそのサービスに接続することができます。DA がない場合は、特定のサブネット上の SA サーバーが同じサブネット上に出されたブロードキャストだけを受信するので、そのサブネット以外にサービスを置くことはできません。

net.slp.interfaces プロパティーの構成が必要な場合は、マルチキャストがネットワークに配置されておらず、代わりにブロードキャストが使用されている場合です。その他の場合は、不必要な応答の重複や到達できないサービスを避けるために、入念に検討および計画を行なってください。

第 10 章 レガシーサービスの組み込み

レガシーサービスとは、SLP の開発および実装が旧式になっているネットワークサービスのことです。たとえば、ラインプリンタデーモン ( lpsched)、NFS ファイルサービス、NIS や NIS+ ネームサービスなどの Solaris サービスは、SLP で使用する内部 SA を持っていません。この章では、レガシーサービスを通知する場合とその方法について説明します。

• 「レガシーサービスを通知する場合」

• 「レガシーサービスの通知」

• 「レガシーサービスを通知する場合の検討事項」

レガシーサービスを通知する場合

レガシーサービス通知では、SLP UA を使用可能にすることで、ネットワーク上の次のようなデバイスやサービスを検出できます。SLP SA を含まないハードウェアデバイスやソフトウェアサービスを検出できます。たとえば、SLP UA を持つアプリケーションが、SLP SA を含まないプリンタやデータベースを検出する必要がある場合、レガシー通知が必要になります。

レガシーサービスの通知

レガシーサービスは、次の方法で通知できます。

• SLP SA を組み込むようにサービスを変更する。

• SLP が有効でないサービスの代わりにサービスを通知する小さなプログラムを書く。

• プロキシ通知を使用して、slpd にサービスを通知させる。

サービスの変更

ソフトウェアサーバーのソースコードを使用できる場合は、SLP SA を組み込むことができます。SLP 用の C 言語の API と Java の API は比較的簡単に使用できます。C 言語の API のマニュアルページと Java の API のマニュアルを参照してください。サービスがハードウェアデバイスの場合は、製造元が SLP を組み込む PROM を更新していることがあります。詳細は、デバイスの製造元に問い合わせてください。

SLP が使用できないサービスの通知

ソースコードや更新された SLP を含む PROM が使用できない場合は、SLP クライアントライブラリを使ってサービスを通知する小さなアプリケーションを書くことができます。このアプリケーションは小さなデーモンとして機能し、サービスの起動・停止に使用する場合と同じシェルスクリプトで起動・停止します。

SLP プロキシ登録

Solaris の slpd は、プロキシ登録ファイルを使用したレガシーサービスの通知をサポートしています。プロキシ通知ファイルは、移植性のあるフォーマットで書かれたサービス通知のリストです。

SLP プロキシ登録を有効にする方法

1. ホストのファイルシステムまたは HTTP でアクセス可能なネットワーク上の任意のディレクトリに、プロキシ登録ファイルを作成します。

2. サービスについてサービスタイプのテンプレートが存在するかどうかを確認します。

   テンプレートは、サービスタイプのサービス URL と属性を記述したものです。テンプレートを使用して、特定のサービスタイプについて通知の構成要素を定義します。

   • サービスタイプテンプレートが存在する場合は、そのテンプレートを使ってプロキシ登録を構成してください。サービスタイプテンプレートについては、RFC 2609 を参照してください。

   • サービスについてサービスタイプテンプレートを使用できない場合は、サービスを正確に記述する属性の集合体を選択してください。通知に対して、デフォルト以外の命名権限を使用してください。デフォルトの命名権限は標準化されたサービスタイプについてだけ許可されています。命名権限については、RFC 2609 を参照してください。

     たとえば、BizApp という会社にソフトウェアバグの追跡に使用されるローカルデータベースがあるとします。データベースを通知するために、この会社は、サービスタイプ service:bugdb.bizapp を持つ URL を使用します。この場合、命名権限は bizapp になります。

3. 前の手順で作成した登録ファイルの場所を使用して、/etc/inet/slp.conf ファイルの net.slp.serializedRegURL プロパティーを構成するには、次の手順に従います。

4. スーパーユーザーになるか、同等の役割を引き受けます。

   役割には、認証と特権コマンドが含まれます。役割の詳細については、『Solaris のシステム管理 (セキュリティサービス)』の「RBAC の構成 (作業マップ)」を参照してください。

5. ホスト上の slpd とすべての SLP 動作を停止します。

   # svcadm disable network/slp

6. 構成の設定を変更する前に、デフォルトの /etc/inet/slp.conf ファイルのバックアップをとります。

7. /etc/inet/slp.conf ファイルの net.slp.serializedRegURL プロパティーにプロキシ登録の場所を指定します。

   net.slp.net.slp.serializedRegURL=proxy registration file URL

   たとえば、直列化登録ファイルが /net/inet/slp.reg である場合、プロパティーを次に示すように構成します。

   net.slp.serializedRegURL=file:/etc/inet/slp.reg

8. 変更を保存し、ファイルを閉じます。

9. 変更を反映するには、slpd を再起動します。

   # svcadm enable network/slp

SLP プロキシ登録による通知

サービス通知は、サービス URL を特定する行、オプションのスコープ行、一連の属性の定義から構成されます。SLP デーモンはファイルからプロキシ通知を読み、その通知を登録し、SA クライアントと同じようにそれらを保持します。次のリストは、プロキシ登録ファイルの例を示します。

この例では、LPR プロトコルをサポートするレガシープリンタと ftp サーバーが通知されています。行番号は説明のために付け加えたもので、実際のファイルには記述されていません。

 (1) #Advertise legacy printer. 
 (2) 
 (3) service:lpr://bizserver/mainspool,en,65535
 (4) scope=eng,corp
 (5) make-model=Laserwriter II
 (6) location-description=B16-2345
 (7) color-supported=monochromatic
 (8) fonts-supported=Courier,Times,Helvetica 9 10
 (9) 
 (10) #Advertise FTP server
 (11) 
 (12) ftp://archive/usr/src/public,en,65535,src-server
 (13) content=Source code for projects
 (14) 

プロキシ登録ファイルは、ASCII でない文字のエスケープに、構成ファイルと同じ取り決めを使用します。プロキシ登録ファイルのフォーマットについては、RFC 2614 を参照してください。

レガシーサービスを通知する場合の検討事項

通常、SLP を追加する場合、ほかのサービスの代理として SLP API で通知する SLP 対応のサービスを書くよりも、ソースコードを変更する方が望ましい方法です。ソースコードの変更は、プロキシ登録を使用するよりも望ましい方法です。ソースコードを変更する場合、サービス固有の機能を追加したり、サービスの使用可否を綿密に追跡したりできます。ソースコードが使用できない場合は、プロキシ登録を使用するよりほかのサービスの代理として通知する SLP 対応のヘルパーサービスを書く方が望ましい方法です。このヘルパーサービスを、起動と停止の制御に使用されるサービスの開始または停止手順に組み込むことをお勧めします。プロキシ通知は通常、ソースコードが使用できず、スタンドアロンの SA を書くことが実際的ではない場合の 3 番目の選択肢です。

プロキシ通知は、プロキシ登録ファイルを読み取る slpd が動作している間だけ保持されます。プロキシ通知とサービスの間には直接的な関係はありません。通知がタイムアウトしたり slpd が停止したりすると、プロキシ通知は使用できなくなります。

サービスが停止した場合は、slpd を停止する必要があります。直列化登録ファイルを編集してプロキシ通知をコメントにするか削除し、slpd を再起動してください。サービスを再起動または再インストールしたときは同じ手順に従ってください。プロキシ通知とサービスの間に関係のないことがプロキシ通知の主な欠点です。

第 11 章 SLP (リファレンス)

この章では、SLP のステータスコードとメッセージタイプについて説明します。SLP のメッセージタイプは、省略形と機能コードを示します。SLP のステータスコードは、説明と機能コードを示します。ステータスコードは、該当する要求を受信しているか (コード 0)、受信側がビジーであるかを示します。

SLP デーモン (slpd) は、ユニキャストメッセージに対してだけステータスコードを返します。

SLP のステータスコード

SLP のメッセージタイプ