Modello di risoluzione dei nomi
Uno spazio dei nomi fa riferimento a alcune funzionalità da associare (almeno) al protocollo e agli attributi di indirizzamento di un servizio di rete con uno o più nomi descrittivi. Molti spazi dei nomi sono attualmente in uso, tra cui il sistema DNS (Domain Name System) di Internet, Active Directory Domain Services, il bindingery, NetWare Directory Services (NDS) di Novell e X.500. Questi spazi dei nomi variano ampiamente nel modo in cui sono organizzati e implementati. Alcune delle loro proprietà sono particolarmente importanti per comprendere dal punto di vista della risoluzione dei nomi Winsock.
Tipi di spazi dei nomi
Esistono tre tipi diversi di spazi dei nomi in cui è possibile registrare un servizio:
- Dynamic
- Static
- Persistente
Gli spazi dei nomi dinamici consentono ai servizi di registrarsi con lo spazio dei nomi a comparsa e per i client di individuare i servizi disponibili in fase di esecuzione. Gli spazi dei nomi dinamici si basano spesso sulle trasmissioni per indicare la disponibilità continua di un servizio di rete. Gli esempi meno recenti di spazi dei nomi dinamici includono lo spazio dei nomi Service Advertising Protocol (SAP) usato all'interno di un ambiente NetWare e lo spazio dei nomi Name Binding Protocol (NBP) usato da AppleTalk. Lo spazio dei nomi PEER Name Resolution Protocol (PNRP) usato in Windows è un esempio più recente di uno spazio dei nomi dinamico.
Gli spazi dei nomi statici richiedono che tutti i servizi vengano registrati in anticipo, ovvero quando viene creato lo spazio dei nomi. Un esempio di spazio dei nomi statico è i file host, protocollo e servizi usati dalla maggior parte delle implementazioni TCP/IP. In Windows questi file si trovano in genere nella cartella C:\windows\system32\drivers\etc .
Gli spazi dei nomi persistenti consentono ai servizi di registrarsi con lo spazio dei nomi al volo. A differenza degli spazi dei nomi dinamici, tuttavia, gli spazi dei nomi persistenti mantengono le informazioni di registrazione nell'archiviazione nonvolatile in cui rimane fino a quando il servizio richiede che venga rimosso. Gli spazi dei nomi persistenti sono tipificati dai servizi directory, ad esempio X.500 e NDS (Servizio Directory NetWare). Questi ambienti consentono l'aggiunta, l'eliminazione e la modifica delle proprietà del servizio. Inoltre, l'oggetto del servizio che rappresenta il servizio all'interno del servizio directory potrebbe avere un'ampia gamma di attributi associati al servizio. L'attributo più importante per le applicazioni client è le informazioni di indirizzamento del servizio. DNS è un altro esempio di uno spazio dei nomi persistente. Anche se è possibile risolvere i nomi DNS tramite Windows Sockets, il provider di spazi dei nomi DNS in Windows non supporta la registrazione di nuovi nomi DNS usando Winsock. È necessario usare le funzioni DNS direttamente per registrare i nomi DNS. Per altre informazioni, vedere Informazioni di riferimento SU DNS.
Organizzazione dello spazio dei nomi
Molti spazi dei nomi sono disposti gerarchicamente. Alcuni, ad esempio X.500 e NDS, consentono l'annidamento illimitato. Altri consentono di combinare i servizi in un singolo livello di gerarchia o gruppo. Questo è in genere definito gruppo di lavoro. Quando si costruisce una query, è spesso necessario stabilire un punto di contesto all'interno di una gerarchia dello spazio dei nomi da cui inizierà la ricerca.
Architettura del provider di spazi dei nomi
Naturalmente, le interfacce a livello di codice usate per eseguire query sui vari tipi di spazi dei nomi e registrare le informazioni all'interno di uno spazio dei nomi (se supportato) differiscono ampiamente. Un provider di spazi dei nomi è un componente software residente in locale che sa come eseguire il mapping tra lo spazio dei nomi Winsock SPI e alcuni spazi dei nomi esistenti (che possono essere implementati localmente o accessibili tramite la rete). L'architettura del provider di spazi dei nomi è illustrata come segue:
Si noti che è possibile che uno spazio dei nomi specifico, ad esempio DNS, disponga di più di un provider di spazi dei nomi installato in un determinato computer.
Come accennato in precedenza, il servizio termine generico fa riferimento alla metà del server di un'applicazione client/server. In Winsock un servizio è associato a una classe di servizio e ogni istanza di un servizio specifico ha un nome di servizio che deve essere univoco all'interno della classe di servizio. Esempi di classi di servizio includono FTP Server, SQL Server, XYZ Corp. Employee Info Server e così via. Come illustrato nell'esempio, alcune classi di servizio sono ben note mentre altre sono univoche e specifiche per un'applicazione verticale specifica. In entrambi i casi, ogni classe di servizio è rappresentata da un nome di classe e da un identificatore di classe. Il nome della classe non deve necessariamente essere univoco, ma l'identificatore della classe deve essere. Gli identificatori univoci globali (GUID) vengono usati per rappresentare gli identificatori della classe di servizio. Per i servizi noti, i nomi delle classi e gli identificatori di classe (GUID) sono stati preallocati e le macro sono disponibili per la conversione tra, ad esempio, i numeri di porta TCP (in ordine host-byte) e i GUID identificatori di classe corrispondenti. Per altri servizi, lo sviluppatore sceglie il nome della classe e usa l'utilità Uuidgen.exe per generare un GUID per l'identificatore di classe.
La nozione di una classe di servizio esiste per consentire la definizione di un set di attributi che vengono mantenuti in comune da tutte le istanze di un servizio specifico. Questo set di attributi viene fornito al momento della definizione della classe di servizio a Winsock e viene definito come informazioni sullo schema della classe di servizio. Quando un servizio viene installato e reso disponibile in un computer host, tale servizio viene considerato creato e il relativo nome del servizio viene usato per distinguere un'istanza specifica del servizio da altre istanze che possono essere note allo spazio dei nomi.
Si noti che l'installazione di una classe di servizio deve verificarsi solo nei computer in cui il servizio viene eseguito, non su tutti i client che possono usare il servizio. Se possibile, la Ws2_32.dll fornisce informazioni sullo schema della classe di servizio a un provider di spazi dei nomi al momento in cui viene avviata un'istanza di un servizio o viene avviata una query del servizio. Il Ws2_32.dll non archivia naturalmente queste informazioni, ma tenta di recuperarlo da un provider di spazi dei nomi che ha indicato la possibilità di fornire questi dati. Poiché non esiste alcuna garanzia che l'Ws2_32.dll possa fornire lo schema della classe di servizio, i provider di spazi dei nomi che necessitano di queste informazioni devono avere un meccanismo di fallback per ottenerlo tramite mezzi specifici dello spazio dei nomi.
Come indicato sopra, Internet ha adottato ciò che può essere definito un modello di servizio incentrato sull'host. Le applicazioni che devono individuare l'indirizzo di trasporto di un servizio in genere devono prima risolvere l'indirizzo di un host specifico noto per ospitare il servizio. A questo indirizzo aggiungono il numero di porta noto e quindi creano un indirizzo di trasporto completo. Per facilitare la risoluzione dei nomi host, è stato preallocato un identificatore di classe di servizio speciale (SVCID_HOSTNAME). Una query che specifica SVCID_HOSTNAME come classe di servizio e specifica un nome host per il nome dell'istanza del servizio restituirà informazioni sull'indirizzo host se la query ha esito positivo.
In Windows Sockets 2 le applicazioni indipendenti dal protocollo devono evitare la necessità di comprendere i dettagli interni di un indirizzo di trasporto. Pertanto, la necessità di ottenere prima un indirizzo host e quindi aggiungere nella porta è problematica. Per evitare questo problema, le query possono includere anche il nome noto di un servizio specifico e il protocollo su cui opera il servizio, ad esempio FTP su TCP. In questo caso, una query con esito positivo restituisce un indirizzo di trasporto completo per il servizio specificato nell'host indicato e l'applicazione non è necessaria per controllare gli interni di una struttura sockaddr .
Il sistema nome di dominio Internet non dispone di mezzi ben definiti per archiviare le informazioni sullo schema della classe di servizio. Di conseguenza, i provider di spazi dei nomi DNS per Winsock possono ospitare solo servizi TCP/IP noti per cui è stato preallocato un GUID della classe di servizio.
In pratica, questa non è una limitazione grave poiché i GUID della classe di servizio sono stati preallocati per l'intero set di porte TCP e UDP e le macro sono disponibili per recuperare il GUID associato a qualsiasi porta TCP o UDP con la porta espressa in ordine host-byte. Pertanto, tutti i servizi familiari, ad esempio HTTP, FTP, Telnet, Whois e così via. sono ben supportati.
Continuando con l'esempio della classe di servizio, i nomi di istanza del servizio FTP possono essere "alder.intel.com" o "ftp.microsoft.com" mentre un'istanza di XYZ Corp. Employee Info Server potrebbe essere denominata "XYZ Corp. Employee Info Server versione 3.5".
Nei primi due casi, la combinazione del GUID della classe di servizio per FTP e il nome del computer (fornito come nome dell'istanza del servizio) identificano in modo univoco il servizio desiderato. Nel terzo caso, il nome host in cui risiede il servizio può essere individuato in fase di query del servizio, quindi il nome dell'istanza del servizio non deve includere un nome host.
Argomenti correlati