Содержание


Автоматизация управления клиентами с помощью Service Location Protocol

Помогите сетевым клиентам помочь себе

Comments

SLP способен находить в сети сервисы, необходимые для выполнения различных операций. Например, если вы устанавливаете новую систему с доступом в сеть, то возникают вопросы: как настроить получение почты? какой шлюз использовать по умолчанию (для перенаправления нелокальных соединений)? какие сетевые принтеры доступны? Обычно эта информация сообщается системным администратором, а затем каждый компьютер настраивается вручную — это трудоемкий процесс, который приводит к необходимости обновления настроек при появлении изменений, неизбежно происходящих в сетях, а следовательно, требующий постоянного внимания системного администратора.

Поэтому велики преимущества автоматического поиска сервисов в сети и обновления настроек в случае, если сервисы были удалены или перемещены. В этой статье будет представлен протокол Service Location Protocol (SLP), разработанный для упрощения процесса сопровождения настроек. Более подробно будет рассмотрена архитектура протокола обнаружения и предоставления сервисов.

История SLP

Поиск сервиса является важным аспектом современных сетей; если вы посмотрите вокруг, то обнаружите его повсеместное использование. Протокол Dynamic Host Configuration Protocol (DHCP) обеспечивает начальный уровень поиска сервисов, предоставляя не только IP-адреса, но и идентификацию Domain Name Service (DNS), необходимую для того, чтобы осуществлять успешный поиск URL, представленных в виде доменных имен.

DNS был расширен на основе RFC 2782, который описывает запросы сервисов или протоколов, возвращающих адрес, по которому доступен требуемый сервис. Этот RFC обычно называется DNS SRV (или DNS for Service Discovery -- DNS SD) - очень похожий на традиционный DNS, но позволяющий преобразовывать не только доменные имена в IP-адреса, но и сервисы/протоколы в IP-адреса. Например, код

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

запрашивает IP-адреса почтового сервера SMTP (по протоколу TCP) и сервер времени NTP (по протоколу UDP - User Datagram Protocol) в домене mtjones.com.

Существует несколько протоколов, которые в той или иной форме обеспечивают поиск сервисов. В таблице 1 приведены примеры нескольких конкурирующих технологий. Как легко заметить, существует несколько стандартов на технологии автоматического поиска сервисов. Некоторые из них взаимодополняющие (например, широко используемые DHCP и DNS), а другие — конкурирующие (такие как SLP и Universal Plug and Play, или UPnP).

Таблица 1. Протоколы, обеспечивающие некоторые формы обнаружения сервисов
Протокол Описание
DHCPDynamic Host Configuration Protocol - протокол динамической настройки узла (стандарт IETF)
DNSDomain Name Service - сервис доменных имен (стандарт IETF)
ZeroConfZero Configuration IP Networking - набор технологий для автоматического создания IP-сетей (стандарт IETF)
SSDPSimple Service Discovery Protocol - простой протокол обнаружения сервисов (стандарт IETF, используется в Microsoft® UPnP)
LDAPLightweight Directory Access Protocol - облегчённый протокол доступа к каталогам (стандарт IETF)
NISNetwork Information Service - информационная служба сети
BonjourИмена компьютеров Apple® для ZeroConf (ранее Rendezvous)
JiniОткрытая архитектура Java™, включающая динамический поиск (Sun Microsystems)
SalutationПротокол поиска сервисов (Salutation Consortium)
SLPService Location Protocol — протокол обнаружения сервисов (стандарт IETF Standard)

Не будем больше останавливаться на конкурирующих стандартах. Теперь углубимся в SLP, чтобы увидеть что делает этот протокол, как он работает и как его можно использовать в приложениях.

Архитектура SLP

SLP — это протокол динамической настройки приложений, работающих в локальных (LAN) или глобальных сетях (WAN). Клиентом SLP используется для нахождения сервисов на основе типа и атрибута сервиса (например, тип сервиса — принтер, а атрибут - цвет). Провайдером сервиса SLP используется для предоставления самого сервиса, а также его специфических атрибутов (возможностей).

SLP может работать на нескольких архитектурах, включая архитектуры с центральным сервером, кеширующим предоставляемые сервисы, и децентрализованную архитектуру, в которой анонсированные сервисы самостоятельно реагируют на запросы.

Типы устройств SLP

Для начала рассмотрим устройства сети, использующей SLP. SLP описывает три типа устройств:

  • Пользовательский агент (UA)
  • Агент сервиса (SA)
  • Дополнительный агент каталога (DA)

Важно отметить, что приложение может и предоставлять, и запрашивать сервис, то есть работать и как UA, и как SA.

UA - клиент SLP. UA действует от имени приложения для идентификации конкретной услуги в сети. UA идентифицирует услугу, взаимодействуя либо с DA (если он доступен), либо непосредственно с SA. Это будет объяснено более подробно при рассмотрении организации SLP.

SA действует от имени приложения, предоставляющего услугу в сети. Если в сети работает DA, то SA передает DA доступные сервисы и их расположение. В противном случае ответы SA передаются непосредственно в ответ на запрос UA.

DA играет дополнительную роль в SLP - он служит в качестве центральной точки запросов и ответов. При наличии DA ответы сервисов, посылаемые SA, кешируются в DA. Затем, когда UA запрашивают сервисы, то отвечает непосредственно DA. Существование DA означает, что нет необходимости для каждого провайдера анонсировать свой сервис. Один агент регистрирует сервисы от имени других агентов, минимизируя их потери.

Организация SLP

Поскольку существует DA — дополнительный элемент SLP, то методы, которыми SLP-устройства соединяются, могут быть разными. Для начала рассмотрим, как SA и UA определяют наличие DA.

Согласно SLP, обнаружение DA в сети осуществляется двумя способами:

  • Первый, называемый Активный Поиск DA (Active DA Discovery), использует сам SLP для нахождения сервиса DA. UA посылает групповой запрос для service:directory-agent. Каждый DA, получивший этот запрос, передает UA свой адрес.
  • Второй метод поиска DA называется Пассивным Поиском DA (Passive DA Discovery). Согласно этому методу, DA периодически посылает запросы пользователям, чтобы UA и SA знали о существовании DA. В случае, если потерян ответ при Активном Поиске DA, проблему решают периодическое анонсирование DA при пассивном поиске.

Эта архитектура дает SLP некоторую гибкость, однако отсутствие DA может затруднить работу SA.

Поиск сервисов в случае отсутствия DA

Начнем рассмотрение децентрализованной структуры SLP. В этой топологии DA не присутствует в сети; следовательно, UA передают свои запросы SA косвенно. Графическое описание такой структуры представлено на рисунке 1. Поскольку DA отсутствует в сети, SA не способны кэшировать свои сервисы и, следовательно, должны реагировать непосредственно на запросы UA .

Рисунок 1. Поиск сервиса в случае отсутствия DA
Поиск сервиса в случае отсутствия DA
Поиск сервиса в случае отсутствия DA

Из рисунка 1 видно, что UA посылает сервису запрос на идентификацию необходимой услуги. Поскольку DA отсутствует, посылаются многоадресные запросы. Каждый SA предоставляет одноадресный ответ на запрос UA. Ответ идентифицирует сервис и его расположение (адрес и порт).

Поиск сервисов с помощью DA

Когда в сети используется DA, UA и SA соединяются с DA напрямую для запроса и предоставления сервисов. DA обнаруживается Пассивным или Активным поиском DA. В примере, показанном на рисунке 2, и пользовательский агент, и агент сервиса находят DA с помощью Пассивного поиска (с помощью многоадресных сообщений от DA). Результат поиска передается в сообщении DAAdvert от DA.

Рисунок 2. Поиск сервиса с помощью DA
Поиск сервиса с помощью DA

SA анонсирует свою услугу DA сообщением SAAdvert, на которое DA отвечает сообщением SrvAck для подтверждения получения анонса услуги. Когда DA известен SA, они обмениваются одноадресными UDP-сообщениями.

UA запрашивает расположение сервиса из DA сообщением SrvRqst. DA отвечает одноадресным UDP SrvRply, содержащим адрес и порт сервиса.

В больших сетях желательно создавать DA, поскольку это уменьшает количество многоадресных сообщений, пересылаемых по сети. В случае отсутствия DA, каждый SA и каждый UA получают все многоадресные сообщения; большинством агентов эти сообщения игнорируются (поскольку агенты не являются адресатами запроса), что приводит к напрасной трате ресурсов процессора.

Обозначение сервиса

Сервис в SLP определяется сервисным URL, имеющим следующую форму:

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

Здесь <service-type> - это тип сервиса, предоставляющего услугу, а <addrspec> - адрес расположения сервиса (доменное имя или IP-адрес и номер порта). Например, следующий пример представляет почтовый сервер на mail.com, работающий через порт 25:

service:mail://mail.com:25

Если UA запросит местонахождение "service:mail", то адрес будет возвращен вместе с сервисным URL, определяющим его расположение. Отметим, что на запрос может быть возвращено несколько сервисов, и UA решает, который из них будет использоваться. При поиске услуг, для которых ожидается только один провайдер, SLP предоставляет возможности ограничения поиска. Эта возможность обеспечивается областью видимости и позволяет сегментировать сервис для специальных пользователей.

Когда SA анонсирует новый сервис, услуга может ограничиваться конкретной областью видимости. Область видимости — это просто строка, идентифицирующая конкретную зону. Например, если у вас есть 2 принтера, один из которых располагается на первом этаже, а другой — на втором, то вы могли бы определить области как этаж_первый и этаж_второй. Когда UA делает запрос поиска service:printer, будет указана область поиска, ограниченная конкретным этажом.

Вы можете использовать области видимости для определения близости к сервису (например, «на том же этаже») или административной собственности на сервис (например, «бухгалтерия» или «отдел продаж»). Сервис может быть также анонсирован несколько раз в различных областях.

Сообщения SLP

SLP использует несколько сообщений, часть из которых была показана на рисунках 1 и 2. Дополнительно к сообщениям регистрации и обнаружения предусмотрены и сообщения для отмены регистрации сервисов, которые более не предоставляются; поиск сервисов проводится по типу, при этом запрашиваются атрибуты конкретного сервиса.

В таблице 2 перечислены сообщения SLP. Здесь они описываются только для ознакомления — мы не будем рассматривать их подробнее. Если вы используете анализатор протокола Ethereal с установленным плагином SLP, то увидите эти сообщения и передаваемые с ними данные.

Таблица 2. Сообщения SLP
Сообщение От когоКомуОписание
SrvRegSADAРегистрация (анонсирование) сервиса
SrvDeRegSADAОтмена регистрации сервиса
SrvAckDASAОтвет на сообщения SrvReg и SrvDereg
SrvRqstUASA/DAЗапрос расположения сервиса
SrvRplySA/DAUAОтвет на SrvRqst с расположением сервиса
SrvTypeRqstUASA/DAЗапрос расположения сервиса, основанного на определенном типе
SrvTypeReplySA/DAUAОтвет на SrvTypeRqst с передачей адреса расположения сервиса
AttrRqstUASA/DAЗапрос атрибутов сервиса
AttrRplySA/DAUAОтвет AttrRqst с передачей атрибутов сервиса
DAAdvertDAUA/SAПосылается для уведомления UA и SA о существовании и расположении DA
SAAdvertSAUAПосылается для уведомления UA о существовании и расположении SA

Реализация SLP: OpenSLP

OpenSLP — это реализация SLP с открытым исходным кодом, состоящая из API библиотеки, с помощью которой можно создать SA и UA. Также библиотека содержит DA, называемый slpd, настройки которого содержатся в файле /etc/slp.conf.

OpenSLP API основан на архитектуре callback. Вы можете вызвать API-функцию и в контексте этой функции, callback-функция возвращает ответ на запрос или статус. В таблице 3 перечислены API-функции OpenSLP и их назначение. Функции SLPReg, SLPDereg и SLPFind* используют метод callback для возврата своего статуса и дополнительных данных.

Таблица 3. Первичные функции библиотеки OpenSLP
ФункцияОписание
SLPOpenОткрывает экземпляр OpenSLP API
SLPCloseЗакрывает экземпляр OpenSLP API
SLPRegРегистрирует сервис и URL
SLPDeregОтменяет регистрацию URL сервиса
SLPFindSrvsНаходит зарегистрированный сервис заданного типа
SLPFindSrvTypesНаходит все типы сервисов ,зарегистрированных в области видимости

Дополнительно к библиотеке API OpenSLP предоставляет утилиту slptool, которую можно использовать для интерактивного выполнения большинства функций SLP. Эта утилита может быть полезной для регистрации или поиска сервиса. Например, следующий фрагмент демонстрирует поиск сервиса daytime:

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

В разделе Ресурсы даны ссылки на более подробную информацию об OpenSLP API и средствах работы с ним.

Пример использования

Теперь рассмотрим пример клиентского и серверного приложений, использующих OpenSLP API. В этом примере создается сервер daytime : когда клиент подсоединяется, сервер выдает ASCII строку текущего времени. Сначала обсудим код приложений, а затем вы увидите оба приложения в действии.

daytime-сервер на основе SLP

В листинге 1 представлен код daytime-сервера на основе SLP. Код состоит из трех разделов для упрощения описания функционала.

  • Раздел 1 демонстрирует установку сокета.
  • В разделе 2 выполняется регистрация сервиса.
  • В разделе 3 реализован сервис daytime.

В первом разделе устанавливается сокет для сервера daytime. Сначала создается сокет, устанавливается многократное использование адреса с помощью setsockopt, потом сокет связывается с адресом и портом, а затем разрешаются входящие соединения с помощью вызова listen (который устанавливает серверный сокет TCP в состояние прослушивания).

В разделе 2 выполняется регистрация сервиса с помощью OpenSLP API. Сначала создается новый описатель SLP с помощью функции SLPOpen, а затем функцией SLPReg регистрируется сервис. Учтите, что URL сервиса содержит имя сервиса (daytime), его расположение (www.mtjones.com) и номер порта TCP, на котором доступен сервис (45667). После того, как будет вызвана callback-функция SLPReg (slpRegCallback), функция SLPReg завершается и закрывается описатель SLP с помощью вызова SLPClose. Теперь в DA зарегистрирован сервис.

Регистрация сервиса завершена и мы переходим к разделу 3, в котором реализуется сервер daytime. Сервер ожидает новое соединение и при установлении соединения с клиентом сервер выясняет текущее время, преобразовывает его в строку, а затем записывает эту строку в клиентский сокет с помощью API-функции write. Клиент закрывает сокет, и сервер ожидает соединения с новым клиентом.

Листинг 1. daytime-сервер на основе 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];

  /* --------------------------------------
  * Раздел 1 — установка сервера Daytime
   * -------------------------------------*/

   /* Создание нового сокета */
  if ((servsock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
    perror("socket");
    return servsock;
  }

  /* включение повторного использования адреса */
  if ((setsockopt( servsock, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on))) < 0) {
    perror("setsockopt");
    return -1;
  }

  /* привязка сокета к порту 45667 и всем интерфейсам */
  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;
  }

  /* Установка сокета в состояние прослушивания (принятие
  * новых соединений)
   */
  listen( servsock, 5 );

  /* -------------------------------------------
  * Раздел 2 -- Сервис регистрации SLP
   * ------------------------------------------*/

   /* Создание экземпляра  SLP API */
  err = SLPOpen( "en", SLP_FALSE, &hslp );
  if (err != SLP_OK) {
    printf("SLPOpen failed %d\n", err);
    return err;
  }

  /* регистрация сервиса по 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;
  }

  /* регистрация завершена, удаляем экземпляр SLP */
  SLPClose( hslp );

  /* -------------------------------------
  * Раздел 3 — серверный цикл Daytime 
   * ------------------------------------*/

   /* сервис был успешно зарегистрирован, запуск сервера daytime  */
  while (1) {

  /* ожидание клиентского соединения */
    if ((clisock = accept( servsock, (struct sockaddr *)NULL, NULL)) < 0) {
      perror("accept");
      close(servsock);
      return clisock;
    }

    /* получение текущего времени и отсылка его значения клиенту */
    t = time(NULL);
    snprintf( timeBuffer, MAX_BUFFER, "%s\n", ctime(&t) );

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

  }

  close( servsock );

  return 0;
}

Клиент сервера daytime на основе SLP

Клиент сервера daytime, основанного на SLP, разделен на две функции (см. листинг 2). Первая — callback-функция SLP (для функции SLPFindSrvs function), а вторая — основная функция, реализующая функционал клиента сервера daytime.

Вместо независимого обсуждения этих функций, рассмотрим последовательность их работы. Основная функция разделена на две части. Часть 1 реализует определение расположения сервиса SLP. После получения нового описателя SLP handle с помощью SLPOpen, вызывается функция SLPFindSrvs для поиска сервиса service:daytime (с областью видимости, определенной по умолчанию). Callback-вызов этой функции SLP - функция slpSrvURLCallback. Эта функция вызывается для каждого полученного сервиса. В callback-вызове анализируется URL сервиса, возвращаемого функцией SLPParseSrvURL, и для дальнейшего использования сохраняются IP-адрес и номер порта сервиса. Одно замечание по поводу работы функции resolve_name код этой функции представлен в прилагающемся .ZIP-файле, но я не буду полностью его разбирать в целях экономии места. Единственное назначение этой функции состоит в преобразовании доменного имени, представленного в виде строки, в 32-битный IP-адрес.

После того, как все сервисы получены, управление от функции SLPFindSrvs передается функции main и описатель SLP закрывается с помощью вызова SLPClose. Каждый полученный сервис проверяется (используется последний доступный); если сервисы не найдены, то работа завершается.

Последний раздел, Часть 2,- это клиентский сокет daytime. Используя IP-адрес и номер порта, найденные через SLP, создается новый сокет и открывается соединение с сервером. После получения ответа от сервера, клиент считывает данные из сокета и выводит ответ (текущее время).

Вот и все! Код клиента и сервера занимает немного места даже в этом небольшом примере.

Листинг 2. Клиент сервера daytime на основе 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;

  /* проверка успешности завершения callback-вызова */
  if (errcode == SLP_OK) {

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

    /* выделение основных элементов URL сервиса */
    err = SLPParseSrvURL( srvurl, &parsedURL );

    /* если предыдущая операция завершилась успешно, то необходимые элементы
    * сохраняются для использования в приложении. */
    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;

      /* преобразование доменного имени в IP-адрес */
      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) {

  /* бездействие */
    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;

  /* -------------------------------------
  * Часть 1 — запрос сервиса SLP 
   * ------------------------------------*/

   /* Создание экземпляра SLP API */
  err = SLPOpen( "en", SLP_FALSE, &hslp );
  if (err != SLP_OK) {
    printf("SLPOpen failed %d\n", err);
    return err;
  }

  /* пытаемся найти требуемый сервис */
  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;
  }

  /* Удаление экземпляра SLP API */
  SLPClose( hslp );

  /* если сервис не был найден, то выход */
  if (!found) {
    close(sock);
    printf("Service not found.\n");
    return -1;
  }

  /* --------------------------------------
  * Часть 2 — установка клиента Daytime 
   * -------------------------------------*/

   /* создание нового сокета */
  if ((sock = socket(AF_INET, SOCK_STREAM, 0)) < 0) {
    perror("socket");
    return sock;
  }

  /* связывание сокета с обнаруженным сервисом (адресом и портом) */
  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;
  }

  /* чтение времени, переданного сервером daytime */
  in = read(sock, timeBuffer, MAX_BUFFER);
  timeBuffer[in] = 0;

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

  close(sock);

  return 0;
}

Демонстрация работы клиента и сервера

В листинге 3 показано взаимодействие сервера и клиента. Сервер и клиент SLP были созданы с помощь утилиты make. Я запускаю утилиту slpd (SLP DA), а затем запускаю сервер (slpreg). Теперь, когда сервер работает и, вероятно, зарегистрирован, я дополнительно использую slptool, чтобы увидеть, что DA знает об сервисе. Из ответа slptool, понятно, что процесс регистрации завершен, теперь я запускаю клиент slpfind. Это приложение ищет сервис, а затем, после анализа полученного URL сервиса, присоединяется к серверу и получает текущее время.

Вы можете скачать slpreg, slpfind и другие файлы в разделе Загрузки ниже.

Листинг 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Сетевые принтеры и камеры
GroupLogicСистемы совместного использования файлов и принтеров ExtremeZ-IP
IBMCommunications Server; TotalStorage SAN Volume Controller; TotalStorage Multiple Device Manager (MDM); TN3270 Terminal
Open Door NetworksShareway IP - система совместного использования файлов
SymantecNorton Personal Firewall for Macintosh
WBEM SolutionsСервер J WBEM

В нескольких современных операционных системах уже включена поддержка SLP, среди них GNU/Linux®, IBM AIX, HP-UX, NetBSD, Sun Solaris 8, Mac OS X и Novell SuSE Enterprise Server 9. Вы также можете написать свое приложение, использующее протокол SLP, не только на языке C. Некоторые языки программирования, включая C/C++, Java™ и Python, поддерживают работу с SLP.

Наконец, описание SLP может быть найдено в нескольких RFC, рекомендующих его использование (например, iSCSI и FCIP). Несмотря на интеграцию протокола во многие операционные системы, продукты и поддержку в языках программирования, существуют возражения по более широкому принятию SLP. Целый ряд протоколов работает в области поиска сервисов, однако ни один из них не достиг статуса стандарта де-факто.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи (EN).
  • Откройте для себя OpenSLP - реализацию SLP.
  • Взгляните на простую реализацию SLP в книге TCP/IP Application Layer Protocols for Embedded Systems, которую написал М. Тим Джонс.(EN)
  • UPnP - это технология, устанавливающая простую и прочную связь между персональными компьютерами и отдельными устройствами.(EN)
  • Bonjour — это торговая марка Apple для протокола IETF ZeroConf, который обеспечивает поиск сервисов в IP-сетях.(EN)
  • Zero Configuration Networking — официальный стандарт IETF, ориентированный на создание неадминистрируемых систем.(EN)
  • Связки языка Python с SLP доступны на SourceForge.(EN)
  • GNU/Linux демон принтера (CUPS, или Common UNIX Printing System) может использовать SLP для поиска принтеров. Интересная информация по этой теме была представлена на MICON 2000.(EN)
  • Обзор Service Location Protocol (IBM Redbooks Technote, Август 2003).(EN)
  • This Этот файл справки (EN) объясняет работу протокола SLP.
  • Найдите больше ресурсов, полезных Linux-разработчикам, в разделе Linux сайта developerWorks.
  • Создайте свой следующий проект для Linux с помощью пробного ПО IBM, доступного для загрузки с сайта developerWorks.
    (EN)

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Linux
ArticleID=332099
ArticleTitle=Автоматизация управления клиентами с помощью Service Location Protocol
publish-date=08192008