FTP virtual disk driver

The task was to write a utility that allow address to a specific server under FTP protocol by creation of network disk (at that, the disk must look as usual network disk in Windows). Also it was required to supply the maximum independence of separate program components in order to replace FTP protocol, if necessary, with any other without significant expenses.

Contents:

Initial conditions
The problem
Variants of the solution
Results
Tools

Initial conditions

We had little experience in driver development, but we accepted this project – it was a challenge to our abilities and expertise.

The problem

Creation of a network disk in Windows in any case means writing kernel-mode file system driver. Driver writing is connected with the certain difficulties: lack of the documentation (it especially concerns file system drivers), complexity in debugging, etc.

Variants of the solution

The first variant was to implement all functionality at a core level of operating system, i.e. in the driver, and for work with FTP use so-called TDI interface (analogue of sockets library in a core mode). This variant was connected with significant time waste because of insufficient file systems and TDI interface? drivers documentation, very high complexity in debugging, and also with weak flexibility of such system: in case of replacement FTP protocol with any other it would be necessary to rewrite the whole code that works with the network protocol. Besides, in case of adding complex functionality to the protocol (for example, compression or data encryption) it would be needed to implement it in the driver again with all accompanying difficulties.

The second variant (the variant we chose) was to divide the ?program? on low-level and high-level components. Low-level component would be presented by the driver which accepts inquiries from operating system and transfers them to high-level component (to the service working in the user-mode). Service, as well as the driver, would be implemented so that it doesn’t depend on the network protocol used. The whole code, responsible for working with the protocol, would be in the separate dynamic library (DLL) to be loaded by the service at the start.

Results

The chosen approach has provided high simplicity in debugging, protocol implementation (FTP and any other), an opportunity of flexible manipulation with various protocols (while working of the ?program? there is a potential opportunity to load/unload libraries that are responsible for various protocols).

Client was absolutely satisfied and still is working with us.