The Common Internet File System What Microsoft has in store for the Internet with CIFS

September  1996

Distributed File sharing is on the mind of all vendors especially in the light of the advancement of thin clients. In this issue we continue our coverage of Internet and TCP/IP file sharing systems with the introduction of the Common Internet File System. A competitor to Sun's WebNFS project, Microsoft's CIFS provides a distributed file sharing system for all Windows based computer systems as well as supporting the Wide area needs of the Internet. (1,400 words)

Mail this article to a friend

We once shared a common language, but an angry God destroyed mankind's Tower of Babel. Ever since that time, we with the largest brains in the animal kingdom have foolishly developed separate, incompatible languages. By some counts, humans now converse in 5,000 tongues.

The digital world isn't quite so bad off, perhaps because we've had only 50 years or so to fragment the few standards we share. Last month I described WebNFS, a proposed standard protocol for file access and sharing across the World Wide Web. WebNFS is based on NFS, the de facto file sharing protocol in Unix and related midrange computers. This month we explore the Common Internet File System (CIFS), which is Microsoft's answer to NFS in general and WebNFS in particular.

Many, many years ago (in Internet time), Microsoft created the Server Message Block (SMB) and NetBIOS-based file sharing system for its ill-fated LAN Manager. (Pieces of SMB are also found in OS/2.) LAN Manager, a LAN OS for small workgroups, was supposed to kill NetWare but didn't. Then along came Windows NT and the expansion of the Internet for commercial use, so Microsoft is now buffing and polishing LAN Manager's file system, and hanging a sign on it that reads, "Internet-ready, low mileage." So let's open the hood and see how CIFS works and contrast it with the other file sharing mechanisms, proposed and plying the infohighway.

CIFS family values
According to Microsoft's draft specification, CIFS supports:

File and printer access

File access is, of course, assumed to be open, close, read, write, seek, and other very basic file operations. Printers are treated as write-only files and this causes documents to be queued for printing.

File and record locking

File locking is a very basic must for multiuser file access so that no two users interfere with each others' write operations. Record locking is similar except on a finer detail, usually within a file itself.

Safe caching, read-ahead and write-behind data accesses

Caching information locally while reading a file speeds up access to the data. If the file is being written to, then each SMB client is informed by the server of any changes.

File change notification

A client application can register with the server that it should be informed of any modifications to the servers file system when no files are open; this allows the client to update information about the directory structure or file access only when an actual change occurs, rather than having to request the server for this piece of news continually through polling.

Batch requests

The ability to batch file requests is related to caching. The idea here is to allow a group of requests to collect at the local machine and then send them over the network to be processed by the remote server. This is a time sensitive issue because of multi-user access.

Although protocol version negotiation is indicated as one of the features of CIFS, this is such a basic need for a distributed computing environment, we should note it.

Extended file attributes

CIFS allows servers to contain extended file attributes about each file system. Although less efficient computationally than assuming a common set of file attributes, this allows local server file systems to support other components, such as file ownership, content description, and file access control lists. NFS depends on the UNIX file attribute conventions built into the protocol; it does not easily support interesting file system features such as Access Control Lists found in OpenVMS, or the dual resource-data forks in Apple's MacOS file system.

Distributed replicated virtual Volumes

Distributed replication of server volumes is an important feature left out of NFS. This allows servers to automatically direct client applications to replications of itself for any specified purpose. The servers confirm the homogeneity of information across the replicated volumes. This is very computationally expensive and sometimes hard to control in widely distributed servers, but is nonetheless important.

Server hostname resolution using DNS

All server machines supporting CIFS are based upon TCP/IP and thus sport an IP address. The clients need to use the Domain Naming System for resolving globally unique servers. The truth is that, however, DNS is getting tired. DNS needs to support more dynamic address to name conversions, the central thought behind the gestating Dynamic DNS effort.

Unicode filenames

CIFS is one of the few distributed file systems to support Unicode, the international standard for multilingual computing. This means that the file name can be in English, Norwegian, Kanji, Arabic, Hebrew, or any number of non ASCII-based characters. Unicode is significantly larger than ASCII in its character set and is one good, unsung feature of Windows NT and Windows 95. (It may be the only good feature in Windows 95.)

Connection-oriented and connection-less transport mechanisms

SMB protocol can use both connection-oriented and connection-less protocols -- TCP and UDP, respectively. Until recently, NFS officially supported data transport over UDP, making it less than efficient over a WAN.

Trials and tribulations
One horrifying weakness to SMB is its required use of server name mapping. Unlike Internet hostnames, which have a local machine name, maybe a subdomain, and then a domain name for global identification, SMB-based servers have a single name. To reference a file over the network you use a string:

//magickingdom/home/donald/killmickey.txt

A `standard?' Yes and no
Despite its moniker, the Common Internet File System is not yet common on the Internet nor is it a standard. Microsoft offered it to the Internet Engineering Task Force (IETF) as a draft for an informational RFC. On the other hand, X/Open (now the Open Group) published SMB as CAE Specification C209. Microsoft is not taking a page from Sun's WebNFS marketing book in claiming that CIFS is better than HTTP. Instead Microsoft positions CIFS as an alternative to HTTP. This is curious, since HTTP is infamous for its rudimentary file sharing -- a few notches above FTP at best. Microsoft probably aims to continue access to Web pages using HTTP. Instead of creating a new schema as Sun did with the nfs:// schema for WebNFS, Microsoft will probably extend the use of the file:// schema, which is currently underutilized to indicate the local hard drive only.

Support for CIFS
Other vendors have long supported CIFS in one form or another, even blood rivals. Novell, Banyan, Digital, and IBM support SMB-based file sharing in current versions of NetWare, Vines, Pathworks, and LAN Server products, respectively. In addition, top-notch UNIX vendors have also created packages for sharing UNIX file systems through gateways such as AT&T Advanced Server for UNIX, Samba, SCO LAN Manager, and HP Advanced Server 9000. With the new CIFS banner, Intergraph, Data General, and Intel have pledged support for this file system. One curious addition is Network Appliance, builders of quick and inexpensive NFS servers. Its NetApp Multiprotocol Filer supports both NFS and CIFS. Network Appliance's actual file system on the server is a proprietary mechanism designed for speed and accessibility and the actual interfaces are industry standard -- an interesting method to win on both fronts.

CIFS for you, CIFS for me
Like it or not, if you have Windows machines you are using CIFS. Microsoft is making CIFS a common part of all members of the Windows family. The naming systems is still quite outdated and Microsoft is trying to fix this. The much anticipated Open Directory Services Interface (ODSI), which would have also been Microsoft's future competitor to the NetWare Directory Services (NDS) system seems to have gone to the land of abandoned projects. Microsoft has given confusing and sometimes conflicting statements onto the direction it will take with ODSI. The Lightweight Directory Access Protocol (LDAP) has gained some acceptance as a vendor neutral situation which falls somewhere between the computational efficiency of DNS and the complexity of X.500. This is only a naming system not a file system, although the former is required for the latter. Filesystems such as NFS will probably remain in the world of UNIX and heterogeneous networks for at least another decade or two. CIFS will also continue in parallel as long as Microsoft is in existence and probably for sometime after. The moral is to stay on top of the information and understand where they are coming from and where they are going.

Resources

• "What WebNFS means to you"
  /sunworldonline/swol-08-1996/swol-08-connectivity.html
• CIFS Overview
  http://www.microsoft.com/intdev/cifs/
• CIFS 1.0 Internet Draft
  ftp://ietf.cnri.reston.va.us/internet-drafts/draft-heizer-cifs-v1-spec-00.txt
• SMB Programming FTP site
  ftp://ftp.microsoft.com/developr/drg/SMB-Info/
• Microsoft CIFS Press Release
  http://www.microsoft.com/corpinfo/press/1996/jun96/cifs2pr.htm
• Network Appliance CIFS Support
  http://www.netapp.com/products/level3/CIFSds.html

About the author
Rawn Shah is vice president of RTD Systems & Networking Inc., a Tucson, Arizona based network consultancy and integrator. Reach Rawn at rawn.shah@sunworld.com.

If you have technical problems with this magazine, contact webmaster@sunworld.com

URL: http://www.sunworld.com/swol-09-1996/swol-09-connectivity.html
Last modified: