目次


サービス・ロケーション・プロトコルによるクライアント管理自動化

ネットワーク・クライアントの自助力向上

Comments

サービス検出は、ネットワーク内で操作に必要なサービスを検出するための機能です。たとえば、ネットワーク上に新しいデスクトップ・システムをインストールする場合、そのシステムをメール・サーバーやデフォルト・ゲートウェイ(非ローカル接続のルーティングが必要な場合)、あるいは使用可能なプリンターに対応するように構成するにはどうしたら良いでしょうか。一般に、この情報はシステム管理者から伝えられ、マシンごとに手動で構成が行われます。これは時間のかかるプロセスであり、ネットワーク内で変更が必要になるたびにメンテナンスを繰り返さなければなりません。

このため、ネットワーク上でサービスを自動的に検出でき、さらにサービスが削除された場合やロケーションが変更された場合にはサービスを再検出できると非常に便利です。ここでは、このプロセスの簡素化を目的としたプロトコルであるService Location Protocol (SLP)について説明し、サービスのアドバタイズメントと検出に関するプロトコル・アーキテクチャーについて詳しく説明します。

サービス検出の歴史

サービス検出は、現代のネットワークにおける重要な側面です。現在ではさまざまな場面でサービス検出が利用されています。Dynamic Host Configuration Protocol (DHCP)は、第1レベルのサービス検出を行います。このプロトコルはIPアドレスのリースだけでなく、ドメイン名などのURLを正しく解決できるようにDomain Name Service (DNS)識別情報も提供します。

DNSはRFC 2782で機能拡張され、サービスまたはプロトコルの照会によりアドレス・レコードを返せるようになりました(サービスを検出できる場合)。このRFCは一般にDNS SRV (またはDNS for Service Discovery (略してDNS SD))と呼ばれています。完全修飾ドメイン名をIPアドレスに変換する従来のDNSと同様に、DNS SRVでもサービス/プロトコルをIPアドレスに変換することが可能です。次に例を示します。

_mail._tcp.mtjones.com
_ntp._udp.mtjones.com

上記のコードは、mtjones.comドメイン内にあるTCPベースのSMTPメール・サーバーとUser Datagram ProtocolベースのNTPタイム・サーバーにIPアドレスを要求します。

サービス検出を行うプロトコルは複数ありますが、それらの形式はさまざまです。表1に、競合するテクノロジーをいくつか示します。表からわかるように、競合する標準は多数あり、現在一般に利用されているDHCPとDNSのように相補的なものもあれば、SLPとUPnP (Universal Plug and Play)のように競合するものもあります。

表1. 何らかの形式のサービス検出を行うプロトコル

プロトコル説明
DHCPDynamic Host Configuration Protocol (IETF標準)
DNSDomain Name Service (IETF標準)
ZeroConfZero Configuration IP Networking (IETF標準)
SSDPSimple Service Discovery Protocol (IETF標準、Microsoft®;; UPnPで使用)
LDAPLightweight Directory Access Protocol (IETF標準)
NISNetwork Information Service
BonjourZeroConf対応Apple®;;コンピューターの名前(旧称Rendezvous)
Jini動的検出を含むJava™オープン・アーキテクチャー(Sun Microsystems)
Salutationサービス検出プロトコル(Salutation Consortium)
SLPService Location Protocol (IETF標準)

競合する標準についてはこれ以上触れません。ここからは、SLPの機能、SLPの仕組み、SLPをアプリケーションに適用する方法について詳しく説明します。

SLPアーキテクチャー

SLPは、ローカル・エリア・ネットワーク(LAN)またはワイド・エリア・ネットワーク(WAN)で動作するアプリケーション向けの動的構成プロトコルです。SLPをクライアントとして利用すると、サービス・タイプやサービス属性(タイプ-printerや属性-colorなど)を使ってサービスを検出できるようになります。SLPをサービス・プロバイダーとして利用すると、サービスだけでなく利用可能サービスの具体的な属性もアドバタイズできるようになります。

SLPは、セントラル・サーバーがサービス・アドバタイズメントをキャッシュするアーキテクチャーや、アドバタイザーが照会自体に応答する分散型アーキテクチャーなど各種のアーキテクチャーで動作可能です。

SLPアクター

まず、SLP対応ネットワークにおけるアクターを見てみましょう。SLPには次の3種類のアクターがあります。

  • ユーザー・エージェント(UA)
  • サービス・エージェント(SA)
  • オプションのディレクトリー・エージェント(DA)

ここでは、これらの違いについて定義します。ただし、1つのアプリケーションはサービスの要求とアドバタイズの両方を実行できるため、同時にUAにもSAにもなり得る点に注意してください。

UAはSLPにおけるクライアントです。UAはアプリケーションに代わって動作し、ネットワーク上の所定のサービスを特定します。この際にUAはDA (利用可能な場合)を使ってSAとやり取りするか、あるいはSAと直接やり取りします。この概念については、「SLPの構成」で詳しく説明します。

SAはアプリケーションに代わって動作し、ネットワーク上でサービスを提供します。DAがある場合、SAは利用可能なサービスとそのロケーションをDAに伝達します。DAがない場合は、要求の実行時にSAがUAに直接応答します。

DAはSLPにおけるオプションのアクターで、アドバタイズメントや照会の中心点として機能します。DAがある場合、SAが送信したサービス・アドバタイズメントはDAにキャッシュされます。その後UAがサービスを照会するときには、DAが直接応答します。DAがあれば、各サービス・プロバイダーがサービスをアドバタイズする必要がなくなります。これらのサービスに代わって1つのエンティティーでサービスを登録できるため、オーバーヘッドが最小限に抑えられます。

SLPの構成

DAはSLPのオプション要素なので、SLPアクターがやり取りする方法は大きく異なります。そもそも、DAが実際にあるかどうかをSAとUAはどのように判断するのでしょうか。

SLPでは、ネットワーク内でDAを検出する方法が2通りあります。

  • 1つ目はアクティブDA検出で、SLPそのものを使ってDAサービスを検出する方法です。UAがservice:directory-agentのマルチキャスト要求を送信すると、この要求を受け取ったDAが自分のアドレスを使ってUAに直接応答します。
  • 2つ目はパッシブDA検出で、DAが定期的にDAアドバタイズメントを発信し、UAとSAがDAの存在を認識できるようにする方法です。アクティブDA検出のUDP応答が失われた場合は、パッシブDA検出による定期的なアドバタイズメントによって自動的に問題が解決されます。

このアーキテクチャーではSLPの柔軟性がかなり高まりますが、DAが存在しなければSAに大きな負荷がかかります。

DAを使用しないサービス検出

まずは分散構成のSLPから始めましょう。このトポロジーでは、ネットワーク上にDAが存在しないため、UAは要求を間接的にSAに伝達します。図1は、これを図解したものです。DAがないので、SAはサービスをキャッシュできず、このためUAの要求に直接応答しなければなりません。

図1.DAを使用しないサービス検出Service discovery without a DA

Service discovery without a DA

図1では、UAから、必要なサービスを特定するサービス要求が送信されます。DAがないので、要求はマルチキャストで送信されます。要求されたサービスを提供するSAは、ユニキャスト応答でユーザー・エージェントに応答します。この応答により、サービスとそのロケーション(アドレスとポート)が特定されます。

DAを使用したサービス検出

ネットワーク上にDAがある場合、UAとSAはサービス要求とサービス・アドバタイズメントについてDAと直接やり取りします。DAは、パッシブDA検出かアクティブDA検出のいずれかで検出されます。図2の例では、ユーザー・エージェントとサービス・エージェントの両方がパッシブ検出を使って(DAからのマルチキャストによって)DAを検出しています。この検出は、DAからのDAAdvertメッセージでやり取りされます。

図2.DAを使用したサービス検出
Service discovery with a DA

SAはSAAdvertメッセージを使ってサービスをDAにアドバタイズします。DAはこのメッセージにSrvAckで応答し、アドバタイズメントの受信を確認応答します。SAはDAを認識しているため、要求はUDPフレームでDAにユニキャスト送信されます。

UAはSrvRqstメッセージでDAからサービスのロケーションを要求します。DAは、そのサービスのアドレスとポートが含まれたユニキャストUDPのSrvRplyで応答します。

大規模なネットワークにDAがあると、ネットワーク上で送信されるマルチキャスト・メッセージの数を減らせるので便利です。DAがないと、すべてのSAとUAがすべてのマルチキャスト・メッセージを受信しますが大半は無視されるため(大半がそのメッセージの対象ではないため)、ホスト・プロセッサーの無駄遣いになってしまいます。

サービスの定義

SLPでのサービスは、サービスURLによって定義されます。URLは次のような形式になります。

service:<service-type>://<addrspec>

ここで、<service-type>にはアドバタイズされるサービス・タイプが入り、<addrspec>にはサービスのロケーション(ドメイン名またはIPアドレスとポート番号)が入ります。たとえば次の例では、ポート25でmail.comにあるメール・サーバーをアドバタイズします。

service:mail://mail.com:25

UAが「service:mail」のロケーションを要求した場合は、そのロケーションを定義するサービスURLが返されます。複数のサービスが返された場合は、UAがどのサービスを使用するかを決定する点に注意してください。1つだけ返されることが想定されるサービスの場合、SLPではスコープと呼ばれる検索制限方法を使って、特定のユーザーに対するサービスをセグメント化することができます。

SAが新しいサービスをアドバタイズするときには、オプションでそのサービスをスコープに入れてアドバタイズすることができます。スコープとは、特定のゾーンを識別する文字列にすぎません。たとえば、プリンターが2台あり、1台が1階、もう1台が2階に置かれている場合は、first_floorとsecond_floorとしてスコープを定義します。UAがservice:printerの要求を行うときには、特定の階のスコープを適用することで、その階にある(そのスコープに属する)資源のみに限定して検索が行われます。

スコープを使用して、サービスの近接性(同一階上など)やサービスの管理所有権(経理や営業など)を定義できます。また、サービスが共有されている場合は、異なるスコープを使って1つのサービスを複数回アドバタイズすることも可能です。

SLPメッセージ

SLPでは、さまざまなメッセージが実装されます。図1と図2に示したメッセージはその一部です。サービスの登録と検索のほか、使用できなくなったサービスの登録解除、サービス・タイプに基づいた全サービスの検索、特定のサービスの属性の要求などを行うためのメッセージがあります。

表2に、SLPで使用されるメッセージの定義を示します。これらは単に補足情報であり、ここでは詳しく説明しません。SLPプラグインとともにEtherealプロトコル・アナライザーを使用すると、これらのメッセージと解析データを見ることができます。

表2. SLPでやり取りされるメッセージ

メッセージ送信元送信先説明
SrvRegSADAサービスを登録(アドバタイズ)します。
SrvDeRegSADAサービスを登録解除します。
SrvAckDASASrvRegおよびSrvDeregメッセージに応答します。
SrvRqstUASA/DAサービスのロケーションを要求します。
SrvRplySA/DAUASrvRqstのサービス・ロケーション要求に応答します。
SrvTypeRqstUASA/DA定義されたタイプに基づいてサービスのロケーションを要求します。
SrvTypeReplySA/DAUASrvTypeRqstのサービス・ロケーション要求に応答します。
AttrRqstUASA/DA所定のサービスの属性を要求します。
AttrRplySA/DAUAAttrRqstに応答し、サービスの属性を返します。
DAAdvertDAUA/SADAにより送信され、UAとSAにDAの存在とロケーションが通知されます。
SAAdvertSAUASAにより送信され、UAにSAの存在とロケーションが通知されます。

SLPの実装: OpenSLP

OpenSLPはオープン・ソースによるSLP実装です。OpenSLPは1つのAPIライブラリーで構成され、このライブラリーからSAとUAを作成できます。また、slpdと呼ばれるDAもあり、/etc/slp.confにある構成ファイルを使って構成を行うことができます。

OpenSLP APIはコールバック・アーキテクチャーを使用しています。いずれかのAPI関数を使って要求を実行すると、そのAPI関数のコンテキストでコールバック関数が呼び出され、その結果応答データとステータスが返されます。表3に、OpenSLPで使われるAPI関数とその目的を示します。SLPReg関数、SLPDereg関数、SLPFind*関数はすべてコールバックを使って、それぞれのステータスとオプション・データを返します。

表3. OpenSLPライブラリーの主な関数

関数説明
SLPOpenOpenSLP APIインスタンスを開始します。
SLPCloseOpenSLP APIインスタンスを終了します。
SLPRegサービスとURLを登録します。
SLPDeregサービスのURLを登録解除します。
SLPFindSrvsサービス・タイプを指定して登録済みサービスを検索します。
SLPFindSrvTypes特定のスコープに対して登録されたサービス・タイプをすべて検索します。

APIライブラリーのほか、OpenSLPにはslptoolも備わっています。slptoolを使用すると、ほとんどのSLP関数を対話形式で実行できます。このツールは、サービスの登録やサービスの検索に便利です。たとえば、次の抜粋はデイタイム・サービスの検索方法を示しています。

$ slptool findsrvs service:daytime
service:daytime://www.mtjones.com:45667,65535
$

参考文献」セクションには、OpenSLP APIと関連ツールに関する詳細情報のリンクがあります。

使用例

ここでは、OpenSLP APIを使用するサーバー・アプリケーションとクライアント・アプリケーションの例を見てみましょう。この例では、デイタイム・ソケット・サーバーを作成して、クライアントがサーバーに接続すると、サーバーから現在の時刻を示すASCII文字列が返されるようにします。まずはアプリケーションのソースについて説明してから、両方のアプリケーションの動作について説明します。

SLP対応デイタイム・サーバー

リスト1に、SLP対応のデイタイム・サーバーを示します。ここでは機能について説明しやすいように、コードを次の3つのセクションに分けています。

  • セクション1 - 単純なソケット設定
  • セクション2 - サービス登録の実行
  • セクション3 - デイタイム・サービスの実装

セクション1は、デイタイム・サーバー用のソケット設定です。ここでは、ソケットを作成し、setsockoptを使ってソケット用のアドレス再利用を有効にし、アドレスとポートをソケットにバインドし、最後にlistenを呼び出して(TCPサーバー・ソケットをリスニング状態にします)着信接続を許可します。

セクション2では、OpenSLP APIを使ってサービス登録を実行します。まず、SLPOpenで新しいSLPハンドルを作成してから、SLPRegでサービスを登録します。サービスURLには、サービス名(daytime)、サービスのロケーション(www.mtjones.com)、サービスにアクセスできるTCPポート番号(45667)が含まれていることに注意してください。SLPRegのコールバック(slpRegCallback)が呼び出されると、SLPReg関数が完了し、SLPCloseでSLPハンドルが終了します。これでDAにサービスが登録されます。

サービスの登録が完了したら、セクション3に進んでデイタイム・サーバーを実装します。この例では、acceptで新しい接続を待ち、新しいクライアント接続を受信したら現在の時刻を取得し、それを文字列に変換して、APIのwrite関数でクライアント・ソケットに書き込みます。この後、クライアントはソケットを終了して、新しいクラインと接続を待ちます。

リスト1.SLP対応デイタイム・サーバー
#include <stdio.h>
#include <slp.h>
#include <time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <string.h>
#include <unistd.h>

#define MAX_BUFFER      80

void slpRegCallback( SLPHandle hslp, SLPError errcode, void *cookie )
{

  if (errcode == SLP_OK) {
    printf("Service registered\n");
  }

  *(SLPError *)cookie = errcode;

  return;
}


int main()
{
  SLPError err, callback_err;
  SLPHandle hslp;
  int servsock, clisock, on = 1;
  struct sockaddr_in sa;
  time_t t;
  char timeBuffer[MAX_BUFFER+1];

  /* --------------------------------------
   * Section 1 -- Daytime Server Setup
   * -------------------------------------*/

  /* Create a new socket */
  if ((servsock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
    perror("socket");
    return servsock;
  }

  /* Enable address reuse */
  if ((setsockopt( servsock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on))) < 0) {
    perror("setsockopt");
    return -1;
  }

  /* Bind our socket to port 45667 and all interfaces */
  memset( &sa, 0, sizeof(sa) );
  sa.sin_family = AF_INET;
  sa.sin_port = htons(45667);
  sa.sin_addr.s_addr = htonl(INADDR_ANY);

  if (bind(servsock, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
    perror("bind");
    return -1;
  }

  /* Place the socket into the listening state (able to accept new
   * connections).
   */
  listen( servsock, 5 );

  /* -------------------------------------------
   * Section 2 -- SLP Service Registration
   * ------------------------------------------*/

  /* Open an SLP API instance */
  err = SLPOpen( "en", SLP_FALSE, &hslp );
  if (err != SLP_OK) {
    printf("SLPOpen failed %d\n", err);
    return err;
  }

  /* Register the service with SLP */
  err = SLPReg( hslp, "service:daytime://www.mtjones.com:45667",
                 SLP_LIFETIME_MAXIMUM, 0, "", SLP_TRUE,
                 slpRegCallback, &callback_err );

  if ((err != SLP_OK) || (callback_err != SLP_OK)) {
    printf("SLPReg failed %d/%d\n", err, callback_err);
    return err;
  }

  /* Registration is complete, close the SLP instance */
  SLPClose( hslp );

  /* -------------------------------------
   * Section 3 -- Daytime Server Loop
   * ------------------------------------*/

  /* Service was successfully registered, start the daytime server.*/
  while (1) {

    /* Await a client connection */
    if ((clisock = accept( servsock, (struct sockaddr *)NULL, NULL)) < 0) {
      perror("accept");
      close(servsock);
      return clisock;
    }

    /* Get the time and send it to the client */
    t = time(NULL);
    snprintf( timeBuffer, MAX_BUFFER, "%s\n", ctime(&t) );

    write( clisock, timeBuffer, strlen(timeBuffer) );
    close( clisock );

  }

  close( servsock );

  return 0;
}

SLP対応デイタイム・クライアント

ここでは、SLP対応のデイタイム・クライアントを2つの関数に分けています(リスト2を参照)。最初が(SLPFindSrvs関数の)SLPコールバック関数で、2番目がデイタイム・クライアントを実装するmain関数です。

ここでは、これら2つの関数を個々に説明するのではなく、流れの観点から説明していきます。main関数は2つのセクションに分けられ、mainのセクション1ではSLPサービス・ロケーションを実行します。新しいSLPハンドルをSLPOpenから取得したら、SLPFindSrvsを呼び出してサービスservice:daytimeを(スコープdefaultで)検索します。このSLP呼び出しのコールバックはslpSrvURLCallbackです。この関数は、返されるサービスごとに呼び出されます。このコールバックの中で、SLPParseSrvURLを使って返されたサービスURLを解析し、後で使用するためにサービスのIPアドレスとポート番号を格納します。ここでresolve_name関数の使用に注意してください。この関数は付属の.ZIPファイルに含まれていますが、ここでは簡潔にするため使用しません。この関数の目的は、文字列のドメイン名を32ビットのIPアドレスに変換することのみです。

すべてのサービスが返されると、制御権がSLPFindSrvsからmainへ返され、SLPCloseでSLPハンドルが終了します。この後、サービスが検出されたかどうかをチェックし(ここでは最後に検出されたサービスを使用します)、サービスが検出されない場合は終了します。

セクション2はデイタイム・ソケット・クライアントです。ここでは、SLPで検出されたIPアドレスとポート番号を使用して、新しいソケットを作成し、サーバーに接続します。接続したらソケットから情報を読み取り、応答(現在の時刻)を出力します。

以上です。この単純なデモンストレーションでは、クライアントとサーバーのどちらのSLP部分も小さなものです。

リスト2.SLP対応デイタイム・クライアント
#include <stdio.h>
#include <slp.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>
#include <string.h>
#include <unistd.h>


#define MAX_BUFFER      80

int found = 0;

struct sockaddr_in sa;
int    port;


SLPBoolean slpSrvURLCallback( SLPHandle hslp, const char *srvurl,
                              unsigned short lifetime, SLPError errcode,
                              void *cookie )
{
  SLPSrvURL *parsedURL;
  SLPError  err;

  /* Check the callback for success */
  if (errcode == SLP_OK) {

    printf("srvurl = %s\n", srvurl);

    /* Parse the service string into its basic elements */
    err = SLPParseSrvURL( srvurl, &parsedURL );

    /* If the parse was successful, grab the necessary elements and
     * cache them for the application. */
    if (err == SLP_OK) {

      printf("Found %s\n", parsedURL->s_pcSrvType);
      printf("at host %s\n", parsedURL->s_pcHost);
      printf("port number %d\n", parsedURL->s_iPort);

      found = 1;

      /* Resolve the fully qualified domain name to an IP address */
      printf("Resolving host to IP address\n");
      if (resolve_name( &sa, parsedURL->s_pcHost ) == 0) {

        printf("Resolved to %s\n", inet_ntoa(sa.sin_addr));
        port = parsedURL->s_iPort;

      }

      SLPFree( (void *)parsedURL );

    }

    *(SLPError *)cookie = SLP_OK;

  } else if (errcode == SLP_LAST_CALL) {

    /* no action */
    printf("Final call -- slp find done.\n");

  } else {

    *(SLPError *)cookie = errcode;

  }

  return SLP_TRUE;
}


int main()
{
  SLPError err, callback_err;
  SLPHandle hslp;
  char timeBuffer[MAX_BUFFER+1];
  int sock, in;

  /* -------------------------------------
   * Section 1 -- SLP Service Request
   * ------------------------------------*/

  /* Open a new SLP API instance */
  err = SLPOpen( "en", SLP_FALSE, &hslp );
  if (err != SLP_OK) {
    printf("SLPOpen failed %d\n", err);
    return err;
  }

  /* Try to find the desired service */
  err = SLPFindSrvs( hslp, "service:daytime", "default", 0,
                      slpSrvURLCallback, &callback_err );

  if ((err != SLP_OK) || (callback_err != SLP_OK)) {
    printf("SLPFind failed %d/%d\n", err, callback_err);
    return err;
  }

  /* Close this SLP API instance */
  SLPClose( hslp );

  /* If the service wasn't found, exit now */
  if (!found) {
    close(sock);
    printf("Service not found.\n");
    return -1;
  }

  /* --------------------------------------
   * Section 2 -- Daytime Client Setup
   * -------------------------------------*/

  /* Create a new socket */
  if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
    perror("socket");
    return sock;
  }

  /* Bind the socket to the discovered service (address and port) */
  memset( &sa, 0, sizeof(sa) );
  sa.sin_family = AF_INET;
  sa.sin_port = htons(port);

  printf("Connecting to service\n");
  if (connect( sock, (struct sockaddr *)&sa, sizeof(sa)) < 0) {
    close(sock);
    perror("connect");
    return -1;
  }

  /* Read the time from the daytime server */
  in = read(sock, timeBuffer, MAX_BUFFER);
  timeBuffer[in] = 0;

  printf("Client received: %s\n", timeBuffer);

  close(sock);

  return 0;
}

サーバーとクライアントのデモンストレーション

リスト3は、サーバーとクライアントの動作を示しています。ここでは、makeユーティリティーを使ってSLPサーバーとクライアントを構築しています。まずはslpdユーティリティー(SLP DA)を起動し、次にサーバー(slpreg)を起動します。この時点でサーバーは稼働中で、おそらく登録済みであるため、オプションのステップとしてslptoolを使ってDAが現在サービスを認識しているかどうかを確認します。slptoolの戻りから、登録が済んでいることがわかるため、クライアントslpfindを試行します。このアプリケーションはサービスを検索し、結果として返されるサービスURLを解析した後、サーバーに接続して現在の時刻を取得します。

slpreg、slpfind、およびmakefileは、後述の「ダウンロード」セクションからダウンロードできます。

リスト3.SLPサーバーとクライアントのデモンストレーション
# make
gcc -Wall -o slpreg slpreg.c -lslp
gcc -Wall -o slpfind slpfind.c -lslp
# slpd
# ./slpreg &
[1] 9275
Service registered
# slptool findsrvs service:daytime
service:daytime://www.mtjones.com:45667,65535

# ./slpfind
srvurl = service:daytime://www.mtjones.com:45667
Found service:daytime
at host www.mtjones.com
port number 45667
Resolving host to IP address
Resolved to 66.54.202.174
Final call -- slp find done.
Connecting to service
Client received: Sat Apr 16 14:04:26 2005

#

SLPの今後

SLPは、多数の企業が提供する各種製品でリリースされています。それらの企業と製品の一部を表4に示します。

表4. SLPが統合された製品

企業名製品
Axis Communicationネットワーク・プリンターおよびカメラ
GroupLogicExtremeZ-IPファイルおよびプリンター共有製品
IBMCommunications Server、TotalStorage SANボリューム・コントローラー、TotalStorage Multiple Device Manager (MDM)、TN3270 Terminal
Open Door NetworksShareway IPファイル共有製品
SymantecNorton Personal Firewall for Macintosh
WBEM SolutionsJ WBEM Server

GNU/Linux®;;、IBM AIX、HP-UX、NetBSD、Sun Solaris 8、Mac OS X、Novell SuSE Enterprise Server 9を始めとして、最近ではSLPのサポートを組み込んでいるオペレーティング・システムも多数あります。また、SLP対応アプリケーションに使用できる記述言語もCだけではありません。C/C++、Java™、Pythonなどの言語がSLP対応のバインディングをサポートしています。

最後に、SLPは多くのRFCで使用が推奨されています(iSCSI、FCIPなど)。SLPは多数のオペレーティング・システムや製品、言語サポートに統合されているにもかかわらず、SLPの幅広い普及については反対意見もあります。サービス検出を扱うプロトコルは多数ありますが、事実上の標準として位置付けられているプロトコルはまだありません。


ダウンロード可能なリソース


関連トピック

  • M. Tim Jones著によるTCP/IP Application Layer Protocols for Embedded Systemsを読んで、SLPの軽量実装を学んでください。
  • UPnPは、PCやスタンドアローン・デバイスの間を単純に、堅牢に接続するための技術です。
  • Zero Configuration Networkingは、ゼロ管理環境に焦点を当てた、IETFの正式な資料です。
  • Service Location Protocol Overview(IBM Redbooks Technote, 2003年8月)は、SLPの概要を解説しています。
  • このSLP help fileは、このプロトコルを説明しています。
  • SLPに関するOpenSLP implementationについて調べてみてください。
  • Bonjourは、IETFのZeroConfプロトコルに関するAppleの商標であり、IPネットワークでのサービス発見を行うことができます。
  • SourceForgeには、Python language用のSLP language bindingsがあります。
  • GNU/Linuxプリンター・デーモン(CUPS、つまりCommon UNIX Printing System)は、プリンター発見にSLPを使うことができます。この話題に関する興味深い資料がMICON 2000で発表されました。
  • 皆さんの次期Linux開発プロジェクトを、IBM trial softwareを使って構築してください。developerWorksから直接ダウンロードすることができます。

コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=231395
ArticleTitle=サービス・ロケーション・プロトコルによるクライアント管理自動化
publish-date=02222006