Service Location Protocol - Gian-Luca Dei Rossi, matricola 783467
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
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
3Service 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
4naoUopaqsr^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+rHR
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:tt9patNp'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) J9a
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
5delle 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æ-è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.
9Introduzione...............................................................................................................................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
Puoi anche leggere
