Risoluzione dei nomi delle risorse
Una particolarità delle API di rete è costituita dal modo in cui le applicazioni identificano le risorse di rete, come le named pipe, oppure i file su altri computer. Quando un client named pipe desidera aprire una named pipe su un server remoto, deve poterla identificare in modo univoco. NT adotta lo schema UNC per la gestione dei nomi delle risorse di rete, che li specifica nella forma \\servername\resource\subresource. Per esempio, un client named pipe potrebbe aprire su un server una named pipe con il nome di \\mark\pipe\mypipe. Per specificare che le risorse di rete risiedono sul sistema locale, il nome del server può essere sostituito da un punto (per esempio, \\.\pipe\mypipe).
Quando l'applicazione specifica un nome UNC (invece di un nome standard di file, come C:\temp\myfile) con una API del file system di NT (per esempio CreateFile), l'I/O Manager lo passa a un device driver chiamato mup.sys (MUP - Multiple UNC Provider). Un redirector di risorse, come rdr.sys, si registra con l'I/O Manager quale elemento in grado di individuare le risorse sui sistemi remoti. Mup.sys prende i nomi UNC dall'I/O Manager e li passa ai redirector registrati, in modo che vengano esaminati. Questi ultimi esaminano i nomi e verificano se sono in grado di accedere alla risorsa specificata. In caso affermativo, il redirector lo notifica a mup.sys e all'I/O Manager, in modo da ricevere ulteriori richieste relative agli I/O destinati a quella risorsa. In caso contrario, l'applicazione originaria riceve un codice di errore.
E' già stato menzionato il redirector standard NT LAN Manager, rdr.sys, che gestisce le comunicazioni tra i client e i server per la condivisione dei file. Rdr.sys gestisce anche la ricerca dei nomi delle risorse tra i computer che appartengono alle reti Microsoft LAN Manager. Per questo motivo, un client named pipe che specificasse \\mark\pipe\mypipe userebbe indirettamente mup.sys e rdr.sys per connettersi alla pipe sul server Mark.
Quando viene aperta la cartella Network Neighborhood sul desktop, oppure si utilizza NT Explorer per collegarsi a una stampante oppure a una condivisione di file remota, viene utilizzato un altro tipo di risoluzione dei nomi. I provider di rete registrati in corrispondenza della chiave del Registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order implementano il browsing dello spazio dei nomi della rete. Ciascun provider di rete dispone di una libreria, collegata dinamicamente a un'altra libreria Microsoft standard chiamata mpr.dll (MPR - Multiple Provider Router), che carica tutte le librerie provider di rete e le interroga per popolare la cartella Network Neighborhood con i vari computer e le risorse condivise ad essi associate. Ntlanman.dll è il provider RDR; lo si può trovare specificato in corrispondenza della chiave del Registry del provider di rete RDR HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\networkprovider. Il provider di rete RDR DLL si basa sul driver rdr.sys per gestire le inchieste per conto di mpr.dll, e dispone quindi di un'interfaccia privata con il driver rdr.sys. Un'altra libreria provider di rete fornita con NT è costituita dal provider Novell NetWare, che consente alle applicazioni di accedere alle risorse poste sui computer NetWare.
Driver di protocollo
I driver API di rete hanno il compito di prendere le richieste API, e tradurle in richieste di protocollo di basso livello per la trasmissione attraverso la rete. Per portare a termine queste operazioni, i driver API si basano su quelli del protocollo di trasporto in modalità kernel. La separazione tra le API e i protocolli sottostanti offre all'architettura di rete una maggiore flessibilità, dal momento che le API possono usare protocolli differenti. I driver di protocollo compresi in NT nella sua versione di base sono quelli DLC (Data Link Control), NetBEUI, TCP/IP e NWLink, anche se potrebbero essere presenti altri protocolli sotto forma di opzioni, come quello AppleTalk che viene installato con i Services For Macintosh sui server NT.
Il protocollo DLC è relativamente primitivo e viene usato da alcuni mainframe IBM e da qualche stampante di rete HP. Si tratta di un protocollo "grezzo", nel senso che non può essere usato da nessuna API di rete. Le applicazioni che desiderano utilizzarlo devono quindi interfacciarsi direttamente con il suo device driver.
Nel 1985 IBM ha introdotto lo schema NetBEUI, che successivamente è stato adottato da Microsoft quale protocollo di default per le API LAN Manager e NetBIOS. In seguito Microsoft ha migliorato il protocollo NetBEUI; esso rimane tuttavia piuttosto limitato, dal momento che non è instradabile e offre scarse prestazioni sulle reti WAN. Gli è stato assegnato il nome di NetBEUI (NetBIOS Extended User Interface) perchè questo protocollo strettamente integrato con la API NetBIOS; il protocollo che viene implementato dal driver di protocollo NetBEUI di Microsoft è tuttavia quello NBF (NetBIOS Frame Format). L'esplosiva crescita di Internet, e il fatto che essa si basa sul protocollo TCP/IP, ha tuttavia assegnato una maggiore importanza al protocollo TCP/IP di NT. Nel 1969, l'ente DARPA (Defense Advanced Research Projects Agency) ha sviluppato questo protocollo specificamente quale base per Internet; per questo motivo, si tratta di un protocollo caratterizzato da alcune caratteristiche particolarmente amichevoli nei confronti delle reti WAN, come l'instradabilità e le buone prestazioni WAN.
Il driver NWLink consiste nei protocolli IPX e SPX di Novell, e viene offerto da NT per l'interoperabilità con i server Novell NetWare.
Microsoft ha implementato un'interfaccia standard chiamata TDI (Transport Driver Interface) per consentire ai driver delle API di rete di non dover impiegare varie interfacce per ogni protocollo di trasporto che potrebbe venire utilizzato. I protocolli di trasporto che si conformano a questo standard esportano l'interfaccia TDI verso i loro client, compresi alcuni driver API di rete come afd.sys e npfs.sys. Un protocollo di trasporto implementato quale device driver NT è noto con il nome di TDI Server. Dal momento che i TDI Server sono dei device driver, formattano le richieste che ricevono dai client sotto forma di pacchetti IRP (I/O Request Packet).
Le funzioni di supporto nella libreria tdi.sys, insieme alle definizioni incluse dagli sviluppatori e i loro driver, contribuiscono a creare l'interfaccia TDI. Quest'ultima mette a disposizione essenzialmente una convenzione per il modo in cui le richieste di rete vengono formattate in pacchetti IRP. Inoltre, lo standard TDI offre un mezzo che consente ai client TDI di registrare i callback (ovvero funzioni invocate indirettamente) con i TDI Server. Per esempio, quando uno di questi ultimi ricevere i dati dalla rete, può invocare un callback registered-client-receive. Questa funzionalità callback basata sugli eventi dello schema TDI elimina una parte del sovraccarico associato all'allocazione e alla distribuzione dei pacchetti IRP; i client possono avvantaggiarsi di questa funzionalità al fine di raggiungere prestazioni migliori.
Come suggerito in precedenza, una API di rete potrebbe essere in grado di utilizzare soltanto alcuni protocolli. Per esempio, i servizi Workstation e Server non sanno come usare il protocollo TCP/IP. In ogni caso, questi servizi sono in grado di capire l'interfaccia NetBIOS; NT offre un driver chiamato netbt.sys, che implementa una API di programmazione NetBIOS compatibile TDI, al di sopra del driver TCP/IP. Per questo motivo, i servizi Workstation e Server possono utilizzare NetBEUI o NetBIOS sul protocollo TCP/IP. Fortunatamente, tutte le API di programmazione di NT possono usare direttamente o indirettamente i protocolli NetBEUI oppure TCP/IP, raggiungendo in questo modo il massimo della flessibilità sulle reti Windows.
Driver NDIS
Quanto un driver di protocollo intende leggere o scrivere da o verso la rete dei messaggi formattati con il formato del proprio protocollo, deve compiere questa operazione usando una scheda NIC (Network Interface Card), che viene chiamata NAC (Network Adapter Card) da Microsoft. Dal momento che non ci si può aspettare che i driver del protocollo possano conoscere le particolarità di ogni scheda NIC presente sul mercato (quelle proprietarie si contano a migliaia), i produttori mettono a disposizione alcuni device driver in grado di prendere i messaggi della rete e trasmetterli attraverso il proprio hardware proprietario. Nel 1989, Microsoft e 3Com hanno sviluppato congiuntamente la specifica NDIS (Network Device Interface Specification), che consente ai driver di protocollo di comunicare con quelli NIC in modo indipendente dal dispositivo. I driver NIC compatibili con questa specifica vengono chiamati driver NDIS, oppure driver NDIS Miniport.
In NT, la libreria ndis.sys implementa il confine NDIS esistente tra i TDI Server (tipicamente) e i driver NDIS. Come tdi.sys, anche ndis.sys è una libreria helper che viene usata dai client driver NDIS per formattare i pacchetti IRP inviati ai driver NDIS. Questi ultimi si interfacciano con la libreria per ricevere le richieste e restituire le risposte.
Uno degli obiettivi che Microsoft si è posta per la realizzazione della propria architettura di rete era quello di consentire ai produttori di schede NIC di sviluppare senza difficoltà dei driver NDIS, potendo prendere il codice di un driver e passarlo tra Windows 9x e NT. Per questo motivo, invece di fornire unicamente le routine helper boundary NDIS, ndis.sys offre ai driver NDIS un intero ambiente di esecuzione. Questi driver non sono genuinamente NT, dal momento che non possono funzionare senza l'incapsulazione fornita loro da ndis.sys. Lo strato di isolamento avvolge i driver NDIS in modo così completo, che essi non accettano o elaborano i pacchetti IRP. Al contrario, ndis.sys riceve questi ultimi dai TDI Server e li traduce in chiamate nel driver NDIS. I driver NDIS non si devono inoltre preoccupare della rientranza, dal momento che ndis.sys in invoca un driver NDIS con una nuova richiesta prima che il driver abbia terminato di servire una richiesta precedente. Il fatto di essere esente dalla rientranza significa che gli sviluppatori dei driver NDIS non si devono preoccupare della sincronizzazione complessa, che viene resa ancora più complicata a causa dell'esecuzione parallela possibile sui sistemi multiprocessore. Anche se la serializzazione da parte di ndis.sys dei driver NDIS permette di semplificare lo sviluppo, può tuttavia danneggiare la scalabilità multiprocessore. I driver standard NDIS 4 (la versione NT 4.0 di ndis.sys) non scalano bene per certe attività sui sistemi multiprocessore. Microsoft ha offerto agli sviluppatori un'opzione di attività de-serializzata in NDIS 5, che sarà disponibile con Windows 2000. I driver NDIS 5 possono indicare a ndis.sys che non desiderano essere serializzati; a questo punto, ndis.sys inoltra le richieste al driver non appena riceve i pacchetti IRP che le descrivono. La responsabilità della sequenzializzazione e della gestione di più richieste simultanee è del driver NDIS, mentre la de-serializzazione offre il vantaggio di poter ottenere maggiori prestazioni multiprocessore. Microsoft ha introdotto la de-serializzazione nella versione di ndis.sys che viene fornita con il NT 4.0 Service Pack 4, anche se non lo ha reso noto pubblicamente.
Il modello NDIS supporta anche i driver ibridi TDI-NDIS, chiamati NDIS Intermediate. Questi ultimi tre sono posti tra i TDI Server e i driver NDIS. Ai TDI Server, un driver NDIS Intermediate appare come un driver NDIS. Microsoft ha introdotto pubblicamente i driver NDIS Intermediate in NT 4.0, quale metodo per gli sviluppatori per scrivere dei driver di cattura dei pacchetti. Questi driver sono in grado di vedere tutto il traffico di rete che avviene su un sistema, dal momento che si trovano tra i driver di protocollo e quelli di rete. Gli sviluppatori impostano su di essi il software in grado di offrire opzioni fault tolerant e di bilanciamento dei carichi di lavoro per le schede NIC.
Lo schema NDIS 5.0 ha introdotto un nuovo tipo di driver NDIS orientato alla connessione. Il supporto per l'hardware di rete orientato alla connessione (per esempio, gli switch ATM) risulta pertanto nativo in Windows 2000, che rende standard nell'architettura di rete di NT la gestione e l'instaurazione delle connessioni. I driver NDIS orientati alla connessione usano una parte delle stesse API che vengono utilizzate dai driver NDIS standard; i primi inviano in ogni caso i pacchetti attraverso connessioni di rete hardware, invece di porli sul medium della rete. Le interfacce offerte da ndis.sys per i driver NDIS, al fine di interfacciarsi con l'hardware delle schede NIC, sono disponibili attraverso alcune funzioni che si traducono direttamente in quelle corrispondenti dello strato HAL (Hardware Abstraction Layer) di NT. Quest'ultimo è costituito da una libreria indipendente dall'hardware, che può essere fornita dai produttori di computer per interfacciare NT con alcune schede madri proprietarie, con un insieme standard di API e un modello hardware esposto.
La figura illustra un completo stack driver di rete e consente di esaminare il modo in cui i componenti Winsock si incontrano con il protocollo TCP/IP e un driver NDIS (la figura non comprende tuttavia l'I/O Manager e lo strato HAL).
Contenuti dell'articolo
Aggiungi un nuovo commento »»»
Per inserire un commento, devi registrarti alla nostra community.
Difficoltà
Stampa 
Download 
10annidi.ASPItalia.com: iscriviti alla competizione e vinci fantastici premi ogni mese!
