The Miracle of the Redirector
The NT network architecture is a modular one. That means if you change one component,
you don't have to rewrite the entire network operating system, like you used to
have to do. That was one of the
major problems in the past; each vendor wrote their own protocol, file system
drivers, and NIC drivers. Each
program that would have to communicate over the network would have to be able to
work with each proprietary protocol.
This was a very difficult situation for the writers of network
programs.
The "modules"
are:
1.
File System
Drivers
2.
Network
Protocols
3.
NIC
drivers
The key to making this modular
structure work are the "boundary" layers that are placed between
adjacent modules:
1.
Between the File System Drivers
and the Transport Protocols is the Transport Driver Interface (It makes sense
that its called the Transport Driver Interface, because its the
"interface" or layer between the File System DRIVERS, and the
TRANSPORT Protocols). The TDI is a Boundary Layer.
2.
Between the Protocol Layer and
the NIC Drivers is the NDIS 4.0 Boundary Layer. The Protocols don't talk to the NIC
Drivers directly. Rather, they have to talk to the NDIS 4.0 component first in
order to communicate with the NIC drivers.
Now, because of the boundary
layers, if I want to change parts of any of the three modules, I can do so
without have to make changes in the other two modules. Before the TDI and the NDIS 4.0
specification, if I made a change in one of the modules, I would have to change
the other two as well, which took a LOT of time.
Now, what are those File System
Drivers all about? There are two
types of File System Drivers:
1.
Local
Examples of local file
system drivers are fastfat.sys (which allows you to access files on a FAT
partition, and ntfs.sys (which allows you to access files on an NTFS
partition)
2.
Remote
The remote file system
drivers allow you to access files over the network. The two major network file system
drivers are the Server service, which allows you to share files over the
network, and the Workstation service, which allows you to access shared files
over the network.
The Workstation service is also known as the
"redirector", or "rdr.sys"
So what happens? If you want to see a file on your local
computer, it calls one of the local file system drivers, fastfat.sys or ntfs.sys
to get those files off the local hard disk. But if you want to get a file from
another computer over the network, the operating system (specifically, the I/O
Manager) will call upon the redirector to get that
file.
It's called the redirector
because the request for the file is "redirected" away from the local
hard disk, and toward a network drive.
Now, the redirector isn't an
"all purpose" redirector.
You have to have different redirectors for each type of network you want
to interact with. If you plan to
access material that is stored on a NetWare Server, then you're going to need a
NetWare redirector installed on your machine. If you want to access files that are
being stored on UNIX machine, then you'll need a UNIX redirector installed on
your machine. The Microsoft
networks redirector is installed by default, so you can access any machine on a
Microsoft network without having to add any extra
software.
The problem is, the way you
access files on these different network requires different types of naming
conventions. For example, to access
a file on a UNIX network, you might have to type:
On a NetWare network, you might
have to type:
SYS:stuff\shared\stuff.doc
It would be a lot easier for us
if we could just use the UNC path for every type of network that we want to
interact with. The UNC path for
both of the above would be:
Well, we can do that with the
help of MUP (multiple UNC Provider).
The multiple UNC provider will automatically and behind the scenes
convert our UNC path to the proper format that each network type can
understand.
How does MUP "know"
how to convert the UNC path to the correct syntax for a specific network? It needs the help of MPR (multiple
provider router). MUP will send the
UNC path of the file we want to access to MPR who will convert it to the proper
syntax for that type of network, and then MPR will send the request to the
appropriate redirector for that network.
For example, I want to get to
the stuff file that lives on the computer named STUFF. The UNC path to this would
be:
However, if the STUFF computer
is a UNIX machine, it might require that the request be formatted like
this:
MUP will convert our UNC path
with the help of the MPR, and then MPR will send the request to the UNIX
redirector.
OK, let's see if we can follow
the path of this entire request:
1.
We go into the network
neighborhood and find the UNIX computer named STUFF, and then we click on the
file name stuff.doc
2.
The I/O Managers realizes that
this is not a local file, so its asks the redirector to take care of this
3.
Well, the redirector needs some
help! When we clicked on the
stuff.doc file in the network neighborhood, it automatically put the request in
the UNC format. Who comes to
help? MUP! MUP will accept that UNC path, and with
the help of MPR, format the request so that the UNIX machine will understand
it. Then MPR will forward this
request to the UNIX redirector
4.
Our UNIX redirector takes the
call. It realizes that the file is
on a network drive, so it sends the request to the next layer down,
5.
The Transport Driver
Interface. Remember that the file
system drivers can't talk directly to the network protocols, so the redirector
politely asks the TDI to send the file request to the Network Protocols.
6.
The Network Protocols are now
carrying the ball (the request for the file). But, like all good players, they know
they need to hand off the request.
Who do they hand this request off to? NDIS 4.0! The Network Protocols don't talk
directly to the NIC drivers, they ask NDIS 4.0 to deal with those NIC
drivers.
7.
The NDIS 4.0 wrapper asks the
NIC drivers to take care of the file request, and the NIC Drivers are happy to
oblige.
8.
The NIC Drivers hand off the
request to NIC, who puts the request onto the "wire" (the network
cabling).
All this takes place on the
Client side, i.e., the computer making the request.
Now, what happens when that
request gets to the other side?
What happens when the request actually gets to the STUFF
computer?
Now we have to deal with another
File System Driver, The Server Service.
The Server service is responsible for dealing with requests for files as
they come over the wire from other computers. Remember that the Server service is a
file system driver, but only handles requests for files that come over the
network.
When we last left off, our
request had been put "on the wire". What happens after its been on the wire
and finds its way to the computer name STUFF?
9.
The NIC picks up the request,
and hands it off to the NIC driver.
10. Now, who does the NIC driver
talk to? The Network Protocols?
NO!!! It has to ask NDIS 4.0 to nicely ask the Network Protocols to take the
request.
11. NDIS 4.0 takes the request, and
hands it off to the Network Protocols.
Who does the Network Protocols send the request to? The File System
Drivers? NO!!! Remember that the
Network Protocols aren't allow to talk to the Network Protocols directly, they
have to ask the Transport Driver Interface to talk to the File System Drivers
for them.
12. The Network Protocols hand up
the request to the TDI, and then the TDI hands the request up to the File System
Drivers.
13. Because this is a request that
came from a remote computer, a "remote" file system driver has to
handle the request first. In this
case the Network File System Driver is the Server Service.
14. The Server Service is
responsible for talking to the local file system drivers on the remote machine
(STUFF). Since the stuff.doc file
is on an NTFS drive, what local file system driver is the Server Service going
to have to talk to? NTFS.SYS. It is the ntfs.sys local file system
driver that knows how to access files on an NTFS drive.
15. Now that the local file system
driver, ntfs.sys has the request for stuff.doc, its going to need some
help. The ntfs.sys needs to ask the
local hard disk driver to turn the disk around to the right place so that it can
access the stuff.doc file. Let's
say this is an IDE hard disk, so the Hard Disk Driver's name is ATDISK.SYS.
16. The Hard Disk Driver atdisk.sys
turns the hard drive around to the right place so that ntfs.sys is able to grab
the file, stuff.doc
17. All Right! The file has been accessed! Now, it needs to make the trip back home
to the computer that requested the file.
Who has the file now? That's
right, the local file system driver, ntfs.sys
18. NTFS.SYS hands the file back
down to the Server Service, since the Server Service knows how to talk to the
network protocols in order to send it back to the computer who sent the
request.
19. The Server Service has the file
now and it knows that its going to have to send the file to the Network
Protocols in order to send it back over the network? Can the Server Service talk to the
Network Protocols directly? NO! Its got to ask the Transport Driver Interface
(TDI)
20. The TDI now hands the file to
the Network Protocols. The Network
Protocols need to hand the file down to the NIC Drivers. Can't the Network Protocols do this?
NO!! The Network Protocols need to talk to NDIS 4.0 first.
21. NDIS 4.0 then hands the file
down to the NIC Drivers, and the NIC Drivers give the file to the NIC
itself. The NIC puts our stuff.doc
file onto the wire to get it back to the computer that requested the file.
22. The file finds its way to the
NIC of the computer that requested the file. The NIC hands the file to the NIC
Drivers.
23. The NIC driver needs to send the
file to the Network Protocols. Can
he do this? NOOOO!! NIC has to talk to NDIS 4.0 first. So, NIC sends the file to NDIS 4.0. NDIS 4.0 sends the file to the Network
Protocols.
24. The Network Protocols now have
the file. And they need to send
this file to the File System Drivers.
We they do this?
NOOOOOO!!! They have to talk
to the TDI first, and the TDI will send the file to the File System Drivers.
25. OK, the TDI has the file, and
sends it to the File System Drivers.
26. But wait. Which file system driver is going to
handle this file? Since this file
was returned from over the network, its going to be the redirector. The redirector always handles files that
are coming in from over the network.
So now the redirector has the file.
27. The redirector hands the file
off to the application that requested the file, so now word opens up and
displays the file stuff.doc
This is the MIRACLE of the
redirector. It is the last two
steps that allow up to read NTFS partitions over the network, even if the
machine that requested the file was a Windows 95 machine. Windows95 machines don't have an
ntfs.sys local file system driver, so they can't see NFTS partitions locally;
but, when they access an NTFS drive over the network, NO PROBLEM! That's because the redirector handles
the file locally, not the local file system driver.
Hope this
helps,
Tom
Thomas W. Shinder, M.D., MCSE,
MCP+I
Microsoft Certified Systems
Engineer
Microsoft Certified
Professional-Internet Specialist
TACTEAM - Training And
Consulting
Dallas,
Texas
http://www.shinder.net
mailto:tshinder@shinder.net