1 Introduction

This document describes the file sharing protocol for a Common Internet File System (CIFS). CIFS is intended to provide an open cross-platform mechanism for client systems to request file services from server systems over a network. It is based on the standard Server Message Block (SMB) protocol widely in use by personal computers and workstations running a wide variety of operating systems. An earlier version of this protocol was documented as part of the X/OPEN (now Open Group) CAE series of standards [7]; this document updates the document to include the latest shipping versions, and is published to allow the creation of implementations that interoperate with those implementations.

The scope of this document is limited to describing requests and responses for file services. Separate documents exist for clients requesting services other than file services, e.g. print services.

Use of the Internet and the World Wide Web has been characterized by read-only access. Existing protocols such as FTP are good solutions for one-way file transfer. However, new read/write interfaces will become increasingly necessary as the Internet becomes more interactive and collaborative. Adoption of a common file sharing protocol having modern semantics such as shared files, byte-range locking, coherent caching, change notification, replicated storage, etc. would provide important benefits to the Internet community.

1.1 Summary of features

The protocol supports the following features:

  • File access

  • File and record locking

  • Safe caching, read-ahead, and write-behind

  • File change notification

  • Protocol version negotiation

  • Extended attributes

  • Distributed replicated virtual volumes

  • Server name resolution independence

  • Batched requests

  • Unicode file names

1.1.1 File access

The protocol supports the usual set of file operations: open, close, read, write, and seek.

1.1.2 File and record locking

The protocol supports file and record locking, as well as unlocked access to files. Applications that lock files cannot be improperly interfered with by applications that do not; once a file or record is locked, non-locking applications are denied access to the file.

1.1.3 Safe caching, read-ahead, and write-behind

The protocol supports caching, read-ahead, and write-behind, even for unlocked files, as long as they are safe. All these optimizations are safe as long as only one client is accessing a file; readcaching and read-ahead are safe with many clients accessing a file as long as all are just reading. If many clients are writing a file simultaneously , then none are safe, and all file operations have to go to the server. The protocol notifies all clients accessing a file of changes in the number and access mode of clients accessing the file, so that they can use the most optimized safe access method.

1.1.4 File change notification

Applications can register with a server to be notified if and when file or directory contents are modified. They can use this to (for example) know when a display needs to be refreshed, without having to constantly poll the server.

1.1.5 Protocol version negotiation

There are several different versions and sub-versions of this protocol; a particular version is referred to as a dialect. When two machines first come into network contact they negotiate the dialect to be used. Different dialects can include both new messages as well as changes to the fields and semantics of existing messages in other dialects.

1.1.6 Extended attributes

In addition to many built-in file attributes, such as creation and modification times, non-file system attributes can be added by applications, such as the author's name, content description, etc.

1.1.7 Distributed replicated virtual volumes

The protocol supports file system subtrees which look like to clients as if they are on a single volume and server, but which actually span multiple volumes and servers. The files and directories of such a subtree can be physically moved to different servers, and their names do not have to change, isolating clients from changes in the server configuration. These subtrees can also be transparently replicated for load sharing and fault tolerance. When a client requests a file, the protocol uses referrals to transparently direct a client to the server that stores it.

1.1.8 Server name resolution independence

The protocol allows clients to resolve server names using any name resolution mechanism. In particular, it allows using the DNS, permitting access to the file systems of other organizations over the Internet, or hierarchical organization of servers' names within an organization. Earlier versions of the protocol only supported a flat server name space.

1.1.9 Batched requests

The protocol supports the batching of multiple requests into a single message, in order to minimize round trip latencies, even when a later request depends on the results of an earlier one.

1.1.10 Obsolescence

Throughout this document, references are made to obsolescent elements of the CIFS protocol. Note that these obsolescent elements are still observed in implementations. The "obsolescent" label only describes that these elements may be removed from implementations, in the future.



Implementing CIFS. The Common Internet File System
Implementing CIFS: The Common Internet File System
ISBN: 013047116X
EAN: 2147483647
Year: 2002
Pages: 210

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net