9. NT Networking
The TDI (Transport Driver Interface) and
NDIS (Network Driver Interface Specification from 3COM and Microsoft, ODI is from Novell)
4.0 Boundary layers modularise the NT network architecture to make life easier for the
programmers. The network card drivers must be compatible with NDIS 4.0 which allows multiple
protocols to be bound to one or more cards. The file Ndis.sys is the 'wrapper' which defines
the software interface used by protocols to communicate with network card drivers. It decides
which protocol is in the frame and passes the frame to the correct layer.
Data Link Control is the protocol used by IBM mainframes and HP Jet Direct printers, in NT it is just
used for that.
The TDI provides a common programming interface for the Workstation service called Redirector
and the Server service called Server that communicate with all the protocols. The TDI
allows the networking components to be independent to save having to restart the whole network
subsystem when there is a change.
The I/O Manager decides if an I/O request is for a local disk or a network resource. The
Redirector allows connections to other server computers by accepting I/O requests for remote
files and redirecting them to a network service on another computer.
Alternative redirectors can be added to allow connections to other network such as Banyan
Vines and Netware. GSNW is one that works for NetWare.
The Server service supplies
the connections to client-side redirectors requesting access to shared files and folders. Disabling
this in Services stops clients accessing shared files and folders. If you run NT on a box
with less than 16Mb you have to start Server service manually.
Distributed applications can run on NT machines such that there are Front-end processes
and Back-end processes. The server could use its processing power to carry out the more
resource hungry back-end processes, or the roles could be reversed. Microsoft Exchange is
a good example of this, Microsoft Access talking to SQL server is another example.
Interprocess Communications Mechanisms (IPC) allow data to flow in both directions
in a distributed processing environment. IPC mechanisms include Named Pipes (bidirectional),
Mailslots (unidirectional), WinSock, RPCs, Network Dynamic Data Exchange (NetDDE uses
NetBIOS e.g. Chat) and DCOM.
Windows Sockets (WinSock) accesses transport protocols and
uses sockets or ports to allow client to server communication. Examples include FTP (port 21),
WWW (port 80) and E-mail (port 76) as a client accesses the Internet via an NT web server.
The Multiple Universal Naming Convention Provider (MUP) connects to remote computers
using the Universal Naming Convention (UNC) in the form of \\server_name\share_name\subfolder\file_name.
It issues requests to lower layer drivers.
When an application first attempts to open a remote file specifying a UNC name the Win32
subsystem receives the request and appends the UNC name to \DosDevices\UNC and calls
the I/O Manager to open the file. The object name is a symbolic link to the \Device\MUP.
The MUP driver receives the request and sends an I/O Request packet to each redirector.
When a redirector recognises the name it indicates how much of the name is unique to it
and MUP caches that part for use directly with the redirector.
If NT has a number of redirectors installed e.g. for NT, Banyan Vines and NetWare for which there
is a corresponding .dll file, then the Multiple Provider Router (MPR) directs browser
requests to the appropriate redirector.
The utility Distributed File System (Dfs) allows the administrator to move file servers
and file shares into logical groups to make it easier for users to browse the network for resources.
There is support for Win95.
The Multiple Provider Router (MPR) supports Win32 network APIs (WNet API)
for applications that do not use UNC names. The MPR recives the WNet commands and
distributes them to the appropriate redirector. Because different vendors use
different interfaces for communicating with their redirector, there are a number
of Provider DLLs that reveal a standard interface for the MPR so that the MPR
can communicate with the relevant Redirector.
|
