CIFS Server Implementation
When operating CIFS over the NETBIOS transport over TCP, connections are established and messages transferred as using NETBIOS session service as specified in RFC 1001 and RFC 1002.
After the server name has been resolved to an IP address, a connection is established by sending a NETBIOS session service Session Request packet to port 139 (for more information, see section 4.3.2 of RFC 1002). The NETBIOS session service requires the client to provide a calling name and a called name. The calling name is not significant in CIFS, except that any subsequent use of an identical name from the same transport address is assumed to represent the same client. The called name is always *SMBSERVER.
A CIFS server running over NETBIOS must accept any session request specifying a called name of *SMBSERVER. It may also support legacy SMB clients by having one or more NETBIOS names and accepting session requests that specify them as the called name.
For interoperability with older SMB servers, a client may retry a failed session request using a new called name. The choice of the new called name depends on the name resolution mechanism used. If DNS is used, the called name should be constructed from the first component of the server's DNS name, truncated to 15 characters if necessary, and then padded to 16 characters with blank (0x20) characters. If NETBIOS was used, then the called named is the NETBIOS name. If these fail, then a NETBIOS Adapter Status request may be made to obtain the server NETBIOS name. The client may then retry the connection with the server NETBIOS name as the called name.
Using CIFS with TCP
When operating CIFS over TCP, connections are established to TCP port 445. Each CIFS TCP packet header starts with a 4-byte field formatted as a byte of zero, followed by three bytes of length. The body of the CIFS packet then follows.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ZERO | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ SMB (Packet Type Dependent) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A CIFS TCP session keep-alive message consists of a byte with value 0x85, followed by three bytes with value zero.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x85 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The keep-alive message may be sent if no messages have been sent for a client-configurable interval. A server receiving such a message must discard it.
Connection Termination
If a server receives a transport establishment request from a client with which it is already conversing, the server may terminate all other transport connections to that client. This is to help recover from the situation where a client is suddenly rebooted and is unable to cleanly terminate its resource-sharing activities with the server.
A server may drop the transport connection to a client at any time if the client is generating malformed or illogical requests. Wherever possible, the server should first return an error code to the client indicating the cause of the termination.
If a server gets a hard error on the transport (such as a send failure) the transport connection to that client may be terminated.
A server may terminate the transport connection when the client has no open resources on the server. It may help performance if this termination is performed only after some time has passed or if resources are scarce on the server, since the transport connection will not need to be reestablished if activity soon begins anew. Client software is expected to be able to reconnect automatically to the server if this happens.
Server Name Determination
The manner in which the client determines the name of the server and the relative name within the server is outside the scope of the CIFS protocol. Some examples of server name determination follow.
In the following URL example, the client takes fs.megacorp.com as the server name and /users/fred/stuff.txt as the relative name.
file://fs.megacorp.com/users/fred/stuff.txt
In the following path example, the client takes corpserver as the server name and \public\policy.doc as the relative name.
\\corpserver\public\policy.doc
In another path example, the client uses x as an index into a table that contains server name and file name prefix entries. If the table entries corresponding to x are corpserver and \public, then the server name and relative name are \\corpserver\public\policy.doc, the same as in the previous example.
x:\policy.doc
Server Name Resolution
The manner in which the client resolves the server name to the transport address of the server is outside the scope of the CIFS protocol. All that is required by CIFS is that a CIFS client must have some means to resolve the name of a CIFS server to a transport address, and that a CIFS server must register its name with a name resolution service known to its clients.
Some examples of name resolution mechanisms include: using the Domain Name System (DNS), and using NETBIOS name resolution (for more information, see RFC 1001 and RFC 1002). The server name might also be specified as the string form of an IPv4 address in the usual dotted decimal notation; for example, "157.33.135.101". In this case, resolution consists of converting to the 32-bit IPv4 address.
The name resolution mechanism used may place constraints on the form of the server name. In the case of NETBIOS, the server name must be 15 characters or less, and be uppercase.
The name resolution method used is implementation-dependent. Using a name resolution mechanism such as DNS encourages interoperability over the Internet.