relazione

Gian-Luca Dei Rossi, matricola 783467
Service Location
Protocol
Corso di sistemi distribuiti, A.A 2002-2003
In questo documento si esporranno le caratteristiche del protocollo SLP, ovvero
Service Location Protocol, uno standard, previsto dall'IETF (Internet Engineering Task
Force), che fornisce una infrastruttura che permette alle applicazioni che operano su
una rete di scoprire o annunciare l'esistenza, la locazione e le caratteristiche dei servizi
disponibili. Questo genere di protocolli sono già presenti in diversi sistemi distribuiti,
basti pensare alle funzionalità di browsing delle reti SMB, oppure alle funzionalità di
rintracciamento dei servizi nelle reti netware (che infatti, nelle ultime versioni, hanno
sostituito il loro protocollo proprietario con SLP).
Questo genere di protocolli permette di evitare la lunga fase di configurazione in
sistemi, quali i computer portatili, che molto spesso cambiano rete, ma anche in reti con
topologia essenzialmente statica, per permettere a tutti gli host di conoscere in tempo
reale quando un nuovo servizio è disponibile nella rete.
I riferimenti più importanti per la definizione della caratteristiche di questo protocollo e
delle modalità di utilizzo da parte della applicazioni sono i seguenti RFC (Request For
Comment)
RFC 2165 - Service Location Protocol (giugno 1997)
RFC 2608 - Service Location Protocol, Version 2 (giugno 1999)
RFC 2609 - Service Templates and Service: Schemes (giugno 1999)
RFC 2614 - An API for Service Location (giugno 1999)
Nel seguito del documento ci riferiremo a SLP intendendone la sua seconda versione
(SLPv2).
!
"#
Il protocollo SLP si propone come uno standard che permette alle applicazioni di non
dover chiedere input riguardante la configurazione degli indirizzi e delle porte dei servizi
attivi. Si preoccupa anche di associare ad ogni servizio degli attributi. L'esempio
classico è quello di una stampante. Il protocollo può segnalare non solo l'esistenza e la
locazione (in termini di indirizzo e porta) del servizio di stampa, ma anche la locazione
fisica dell'apparecchio, e addirittura le caratteristiche e le capacità dello stesso. Un altro
esempio tipico potrebbe essere una rete in cui siano presenti più di un servizio di
autenticazione e distribuzione utenti (ad esempio dei server LDAP o Kerberos) che
servono rispettivamente più di un “dominio” di autenticazione. Tra gli attributi segnalati
potrebbe anche esserci il nome di questo dominio. Le applicazioni degli attributi sono in
effetti infinite, poiché si tratta, come vedremo, di un meccanismo molto generale, non
legato ad un insieme prefissato di chiavi.
2
$%'&)(+*-,)./01/2/34(&5.13
687.97:/+0-;<&>=!$@?A
BC'DFEHGJILK1MND'O
Nelle specifiche SLP si definisce agente una qualsiasi entità software che accetti e
processi i messaggi del protocollo SLP.
In una rete in cui siano in funzione degli agenti SLP, bisogna distinguere quali tipi, tra
questi agenti, potranno presentarsi, e per la precisione uno di questi tre
User Agent (UA): un'entità software checerca la locazione di uno o più servizi.
Service Agent (SA): una entità software che fornisce la locazione di uno o più
servizi.
Directory Agent (DA): si tratta di una entità centralizzata che mantiene un database
dei servizi disponibili e della loro locazione.
PRQ
ITSUSUEHGVGDWO
Per cominucare tra loro, gli agenti SLP utilizzano 11 differenti tipi di messaggi. Lo
schema tipico di “conversazione” tra gli agenti è un banale richiesta-risposta, con
alcune eccezioni. I nomi (e relativa semantica) dei messaggi sono i seguenti
Service Request (SrvRqst): messaggi spediti dagli User Agent ai Service Agent ed
ai Directory Agent per richiedere la locazione di un servizio.
Service Reply (SrvRply): messaggi spediti dai Service Agent e dai Directory Agent
in risposta ad una Service Request. Il Service Reply contiene l'URLdel servizio
richiesto.
Service Registration (SrvReg): messaggi mandati dai Service Agent ai Directory
Agent contenenti informazioni sui servizi disponibili.
Service Deregistration (SrvDeReg): messaggi mandati dai Service Agent ai
Directory Agent per notificare che un servizio non è più disponibile.
Service Acknowledge (SrvAck): una generica conferma spedita dai Directory Agent
ai Service Agent in risposta ai Service Registration e ai Service Deregistration.
Attribute Request (AttrRqst): messaggi mandati dagli User Agent per richiedere gli
attributi di un servizio.
Attribute Reply (AttrRply): messaggi spediti dai Service Agent e dai Directory
Agent in risposta alle Attribute Request, contenti la lista degli attributi richiesti.
Service Type Request (SrvTypeRqst): messaggi spediti dagli User Agent ai
3
Service Agent ed ai Directory Agent per richiedere i tipi dei servizi disponibili.
Service Type Reply (SrvTypeRply): messaggi spediti dai Service Agent e dai
Directory Agent in risposta alle Service Type Request, contenti una lista dei tipi di
servizi richiesti.
DA Advertisement (DAAvert): messaggi spediti dai Directory Agent per far sapere
ai Service Agent ed agli User agent la loro locazione.
SA Advertisement (SAAdvert): messaggi spediti dai Service Agent per far sapere
agli User Agent la loro locazione.
Riassumiamo nella tabella sottostante tutte le possibili comunicazioni.
Tipo
Mittente Destinatario
Contenuto
SrvRqst
UA
SA,DA
Richiesta della locazione per un servizio
SrvRply
SA,DA
UA
Risposta ad una SrvRqst
SrvReg
SA
DA
Registrazione di un servizio
SrvDeReg
SA
DA
Deregistrazione di un servizio
SrvAck
DA
SA
Riposta a SrvReg o a ServDeReg
AttrRqst
UA
SA,DA
Richiesta degli attributi per un servizio
AttrRply
SA,DA
UA
Riposta ad una AttrRqst
SrvTypeRqst
UA
SA,DA
Richiesta dei servizi disponibili
SrvTypeRply
SA,DA
UA
Risposta ad una SrvTypeRqst
DAAvert
DA
SA,UA
Locazione dei DA
SAAdvert
SA
UA
Locazione dei SA
XZY\[^]_1`aYb[U[^]dceFfgNe!gih:jTYUkl]ih_:]Wm
Le locazioni, nel protocollo SLP, vanno indicate attraverso una SLP URL (Uniform
Resource Locator). La forma di questi url è la seguente:
service:tipodiservizio://specificaindirizzo
un esempio è il seguente:
service:ftp://fenice.dsi.unive.it:21
oppure
service:imaps://squit.dsi.unive.it;auth=ldap
oppure ancora:
service:printer:lpr://pascal.dsi.unive.it
4
naoUopaqsr^tNpauvrHw
Tutte le richieste di registrazione SLP contengono un campo che esprime un tempo
di vita in secondi: trascorso questo periodo la registrazione non sarà più ritenuta valida
se non interverrà una nuova richiesta. Il massimo tempo di vita consentito dalla
dimensione della rappresentazione del tipo è di 65535 (216-1) secondi, pari a circa 18
ore.
nao^xTyRu{z|~}q+rH€R‚
Il campo fresh ha un tipo booleano ed identifica, se vero, che la registrazione andrà a
sostituire eventuali registrazioni per lo stesso tipo di servizio e la stessa URL. Se
impostato a falso, invece, si avrà una registrazione incrementale (non supportata da
tutte le implementazioni), che aggiunge elementi mancanti o incompleti, soprattutto
negli attributi.
ƒ
o'pFy:tt9„pa…‡†‡tNp'w
Come abbiamo già visto gli attributi sono una peculiarità fondamentale del protocollo
SLP, ed il loro punto di forza è la generalità dei dati rappresentabili. Infatti, anziché
limitare il numero, il tipo o il significato delle informazioni, si è scelta una
rappresentazione “neutra” attraverso stringhe. Generalmente si ha questa sintassi:
“(attributo1=valore1),(attributo2=valore2),(attrN=valoreN)”
ˆŠ‰Œ‹+‰1Ž)‘‰’‹“”J•–—9•Š•Ša˜Ž‘‰™
SLP è basato essenzialmente sulla modalità di comunicazione Multicast, ovvero
trasmette i messaggi solo a coloro che sono registrati in un gruppo, e che quindi
intendono ascoltare questi messaggi. Il vantaggio di questa soluzione è che il mittente
deve mandare una sola copia del messaggio, e saranno poi i router a decidere a chi
mandare i messaggi e a chi no. A livello di rete locale il messaggio multicast viene
“sentito” solo da coloro che sono registrati per quel gruppo (rappresentato da un
indirizzo).
SLP tuttavia è in grado di funzionare anche in altre due modalità, previste per
compatibilità verso quegli host o quei router che non supportano il multicast. Si tratta
5
delle classiche modalità Unicast e Broadcast. La prima è la normale modalità di
comunicazione uno ad uno, la seconda è la modalità di comunicazione da uno a tutti gli
host di una rete. Entrambe le modalità presentano svantaggi, in particolare usare
comunicazioni unicast porta ad un traffico troppo elevato, qualora gli host a cui mandare
messaggi siano troppi, mentre la modalità broadcast impegna inutilmente le sottoreti
che non hanno in realtà alcun host interessato alla comunicazione. Per motivi di
sicurezza inoltre, solitamente i router scartano messaggi destinati all'indirizzobroadcast
provenienti dall'interfaccia esterna.
šŠ›œŸž 9¡
I programmatori che intendono usufruire di SLP nelle loro applicazioni non
abbisognano assolutamente di conoscere i dettagli dei messaggi di comunicazione
sopra esposti. Allo scopo di facilitare il lavoro dello sviluppatore di applicazioni, infatti,
l'IETFsi è occupata anche di definire una API (Application Program Interface) uniforme
per ogni implementazione, formata da semplici funzioni che eseguono le operazioni
“naturali” per questo genere di protocolli. L'APIè stata definita principalmente per il
linguaggio C, ma può essere adattata a qualsiasi altri linguaggio. I nomi delle funzioni
principali (senza la sintassi completa) sono i seguenti
SLPReg() : Registra l'URL di un servizio ed i suoi attributi.
SLPDeReg() : Annulla una precedente registrazione.
SLPFindSrvs() : Trova i servizi disponibili, in base al tipo di servizio o agli attributi.
SLPFindAddrs() : Ottiene una lista di attributi per i servizi registrati con SLP.
SLPFindSrvTypes() : Ottiene una lista del tipi di servizio registrati con SLP.
¢£N¤b¥:¦+§H¨©¨lªU«
Nella sua seconda versione, il protocollo SLP fa ampio uso di elementi di crittografia,
utilizzando in particolare l'algoritmoDSA assieme a SHA-1, e delle firme digitali
conformi allo standard X.509v3 per i certificati.
6
¬!­
®°¯@±1²³´µ:¶J´·¹¸µº±Šµ±:·+»-¼—µV½µ1´a¾@¿1¶ÀZµa¾Á‘»½)»Jµ1±V»)¸Â¯@µ9ÀZµ²
SLP, come già abbiamo visto nell'introduzione,non è di certo l'unicoprotocollo per la
locazione dei servizi. Tuttavia la sua generalità ne fa uno strumento molto più potente e
flessibile. Vediamo perchè.
Ã@ÄVÅ>ÆÈÇUÉbÊË^Ì+ÍFÎ^Ï:ÌÐ{Ã@ÑÓÒÔÐÍTÊ^Õ4Ö-Ã-É
Una feature relativamente recente dei DNS moderni è quella di poter contenere dei
record di tipo SRV. Questi record definiscono la locazione di un servizio per un
determinato dominio. Tuttavia al momento quasi nessuna applicazione ne fa uso, in
quanto la presenza di questo record è considerata ancora sperimentale. Tra i vantaggi
della soluzione con dns troviamo il fatto di poter adattare in poco tempo il resolver sui
client per poter usufruire di questo servizio, nonché la presenza, in questo tipo di campi,
di una priorità che identifica, in caso di più servizi dello stesso tipo, quale scegliere per
primo.
Gli svantaggi sono però chiari: si tratta di un servizio centralizzato, limitato alla
funzione che in SLP spetta ai Directory Agent, e senza possibilità, per giunta, di essere
modificato (se non creando enormi falle di sicurezza nel name server) da eventuali
fornitori di servizi. Infine c'èda far notare che questa configurazione non prevede la
presenza di attributi, molto utili nel caso in cui si vogliano solo i servizi che rispondano a
determinate caratteristiche.
Ã@ÄVÅ>ÆÈÇUÉbÊËFÇ×ÍUÌØÆÈÊWÙlÊiÏÚÐÊ^ÄÏ:ÎLÛFÙdÊNÏ܇ÍÝÐÍTËdޑÌ+χßÏ:ÎbÏZË'ËiÏ{Ã)à\á@É
I servizi di locazione previsti dal protocollo SMB sono pensati unicamente per
annunciare sulla rete la presenza della macchina su cui stanno girando, ed eventuali
condivisioni per dischi e stampanti. Si tratta perciò di un protocollo special purpose, e
per di più non adatto a reti di grosse dimensioni e/o non contigue.
Ã@ÄVÅ>ÆÈÇUÉRÕ4â#ã@Å1É
Il protocollo DHCP (Dynamic Host Configuration Protocol) prevede, tra le sue
funzionalità, quella di comunicare ai client, oltre all'indirizzodell'host,dei dns e del
gateway, anche alcuni indirizzi di un limitato numero di servizi. Tuttavia nel complesso
non si tratta di un servizio di locazione comparabile a SLP poiché
7
ä
si tratta di un servizio centralizzato
ä
il numero di servizi annunciabili è fisso e limitato
ä
la comunicazione avviene solo nella fase di bootstrap della connessione e alla
scadenza del periodo di validità di un lease
ä
funziona esclusivamente in broadcast, non si tratta quindi di una soluzione scalabile.
åŠæ°çèêé)ëaæ-è<æ-ìí+î‘ïçðì)çñ
SLP è stato implementato da diversi gruppi, con esiti differenti, e per fornire diversi
tipi di funzionalità. L'implementazioneche risulta essere più utilizzata è OpenSLP, che
utilizza una licenza libera BSD, che si propone con un server SLP adatto ad essere
eseguito dai Service Agent e dai Directory Agent, ed una libreria C che può essere
usata da tutti i tipi di agenti per accedere alle API. È inoltre disponibile un porting per il
linguaggio Java, il che rende disponibile la libreria in tutti i sistemi operativi e le
architetture che posseggono una Java Virtual Machine.
Sun fornisce una reference implementation del protocollo SLP chiamata da alcuni
“miniSLP”. Questo progetto non intende fornire una versione da usare in ambiti
professionali ma solo una “traccia” per le altre implementazioni.
Esiste poi una versione chiamata mSLP, ovvero Mesh-enhanced Service Location
Protocol, una implementazione che modifica il protocollo e la struttura degli agenti
creando topologie totalmente connesse tra gli agent, per aumentare l'affidabilitàdel
sistema.
LDAP enabled SLP si propone invece come una implementazione di SLP che usa un
server LDAP come backend per il Directory Agent, permettendo la conservazione di
grandi quantità di dati.
Novell Netware infine include, dalla versione 5, una implementazione della prima
versione di SLP, in sostituzione a SAP.
ò
å
óêæôõçºöç9öVíæè—çVôç9öVí¹÷çø)ù
ç'íç9ñ
L'utilità di SLP nei sistemi distribuiti appare subito evidente nei casi in cui
ä
si abbiano agenti mobili
ä
si abbia una grande dinamicità nella distribuzione dei servizi
ä
si abbia un rapido turn-over dell'hardware, richiedendo ad ogni cambio reinstallazioni
8
del software di sistema ed applicativo.
La migrazione da sistemi che richiedono input all'utente(o file di configurazione
dall'amministratore)potrebbe essere rallentata dal fatto che è necessario effettuare
delle piccole modifiche al codice del software ed il linking alla libreria adeguata. Tuttavia
l'impatto in termini di lavoro risulta quasi trascurabile per via della semplicità delle API.
Un'interessantissima applicazione del protocollo SLP, dovuta al fatto che già
esistono delle implementazioni in Java, riguarda la telefonia mobile. Infatti sempre più
telefoni cellulari contengono al loro interno una Java Virtual Machine, che potrebbe
interpretare agevolmente il codice per gestire SLP. Pensiamo alla possibilità, da parte
dei cellulari, di “scoprire” quali servizi (IP) sono disponibili in quel momento ed in quella
zona. Andando oltre con l'immaginazione, si potrebbe pensare a centraline che,
sapendo sempre quali tipi di servizi fornisce il telefono (che in questo caso diventerebbe
un service agent), potrebbe effettuare funzionalità di “push” verso di questo, o
addiruttura sfruttarne, tramite un apposito protocollo (questa parte NON riguarda
direttamente SLP) la capacità di calcolo (esigua, ma va moltiplicata per il numero di
cellulari nel mondo) per scopi scientifici o quant'altro.
û
ú!ûü)ýûþ
ÿ
Di seguito alcuni link che sono risultati utili per la stesura del testo e che possono
esserlo per approfondire la questione (oltre agli RFC citati in apertura).
ä
http://www.ietf.org/
ä
ä
Internet Engineering Task Force.
http://www.srvloc.org/
ä
ä
Service Location Protocol Project.
http://www.openslp.org/
ä
ä
OpenSLP.
http://mslp.sourceforge.net/
ä
Mesh-Enhanced Service Location Protocol.
9
Introduzione...............................................................................................................................2
Utilità di SLP..............................................................................................................................2
L'architettura di un sistema SLP.
.............................................................................................3
Gli agenti...............................................................................................................................3
I messaggi.............................................................................................................................3
La sintassi per le locazioni..................................................................................................4
Il lifetime................................................................................................................................5
Il campo “fresh”.....................................................................................................................5
Gli attributi.............................................................................................................................5
Le tecniche di trasmissione......................................................................................................5
Le API.........................................................................................................................................6
Sicurezza...............................................................................................................................6
SLP vs. gli altri sistemi di locazione dei servizi......................................................................7
SLP vs. il record SRV dei DNS...........................................................................................7
SLP vs. il servizio di Locazione del protocollo SMB.........................................................7
SLP vs. DHCP......................................................................................................................7
Le implementazioni...................................................................................................................8
SLP ed i sistemi distribuiti........................................................................................................8
Bibliografia.................................................................................................................................9
10