Protocol Negotiation and Session Setup continue…

Readingand Writing

The SMB protocol uses the READ and WRITE message types to perform I/O operations on a file for the client. Using the READ request, a client can request that the server return information from the file by specifying a number of bytes and an offset into the file. The server returns the data, indicating the actual number of bytes returned, which can be less than requested if the user tries to read past the end of a file.

The WRITE command updates a file in a similar manner. The client sends in the data that will be written, indicating the number of bytes to write and an offset into the file where the write operation will begin. If the request causes a write past the end of the file, the file is extended to make it larger. The server sends a response telling the client the number of bytes that were written. If the number is less than the requested value, an error has occurred.

To increase read/write performance, the READ_RAW and WRITE_RAW message types can be used to exchange much larger blocks of information between the client and the server. When these are used, the client must have only one request issued to the server. In one send, the server will respond with data that can be as many as 65,535 bytes in length. The WRITE command works in the opposite direction, allowing the client to send a large buffer of raw data to the server for a write operation.

Locking Mechanisms

Locking allows a particular client exclusive access to a file or a part of a file when it is shared on th network. In SMB, the capability to create a lock is called an opportunistic lock, or oplock for short. This is better explained by looking at the way in which it works. A client can create a lock on a resource using three kinds of locks. The first is an exclusive lock, in which the client has exclusive access to the data held by the lock. A batch oplock is one that is kept open by the server when the client process has already closed the file. A Level II oplock is one in which there can be multiple readers of the same file.

The locking process consists of the client requesting the type of lock it wants when it opens the file. The server replies to the client with the type of lock that was granted when it responds to the open request.

A lock gives the client the capability to efficiently manage buffer space it uses when accessing a file over the network. For example, if a client has exclusive access to a file and is performing writes to it, it can buffer a lot of the newly written information before having to send it to the server to update the file. This can provide a reduced number of network packets when updating a file. A client that has an exclusive lock on a file can also buffer read-ahead data to make reading a file much faster.

These locks are called opportunistic locks for a reason. A client can be granted exclusive access to a file if no other client has it open at the time of the request. What happens when another client needs to read the file? The server notifies the first client that it needs to break the exclusive lock. The client then flushes its buffers so that any data that has not been written to the file is processed. The client then sends an acknowledgment to the server that it recognizes that the exclusive lock has been broken.

Batch oplocks are used to reduce the amount of traffic on the network when some programs require continual reopening of a file to obtain commands, as when a batch command procedure is executed.

For example, a batch procedure executed by the command processor usually opens a file, locates the next line to be executed, reads that line, closes the file, and then executes the command. The problem with this is that these steps are taken for each command line in the procedure, resulting in multiple file open/closes that are not really necessary.

This procedure for reading individual lines from a file is done by using a batch oplock whereby the client can read the data from its local read-ahead cache instead of reopening the file on the remote server to get each line.

Level II oplocks were new with the NT changes to SMB. This kind of lock allows more than one client to have a file opened for reading. When a client must read from a file that is opened by another exclusively, the server informs the current client that its exclusive lock has been broken and is now a Level II oplock. No client that has a Level II oplock will buffer data to or from the file. Thus, after the lock has changed to a Level II oplock (and the first client has flushed any data in its buffers), both clients can continue reading the file.

Protocol Negotiation and Session Setup

SMB has a built-in mechanism that is used by the client and server to determine the other's capabilities so that a common protocol version can be established that the two will use for the network con• nection. The first SMB message that the client sends to the server is one of the SMB_COM_NEGOTIATE type. The client uses this message to send the server a list of the dialects it understands. The server selects the most recent dialect it understands from the client's list and returns a message to it.

The response the server returns depends on the type of client. The information includes the dialect selected and can include additional information, such as buffer sizes, supported access modes, time and date values, and security information. After the client receives this response, it can continue to set up the session by using the SESSION_SETUP_ANDX message type.

If the initial server response indicates that user-level security is being used, this message type can be used to perform a user logon. The client sets a value in the message header called the UID (user ID) for the account it wants to use. It also supplies the account name and password to the server by using this message type. If these values are validated by the server, the user can continue to use the UID to make subsequent accesses.

Other setup functions that are performed by using SESSION_SETUP_ANDX include the following:

• Set the maximum values for the size of buffers that will be used in the message exchange.
• Set the maximum number of client requests that can be outstanding at the server.
• Set the virtual circuit (VC) number.

If the VC passed to the server is zero and the server has other circuits open for the client, it will abort those services, assuming that the client has rebooted without freeing those services first. To properly close a session, the client uses the message type LOGOFF_ANDX, which causes the server to close all files associated with the user's UID.

Accessing Files

Other SMB message types are used to traverse the resource directory and to open, read, write, and close files. First, the user must connect to the resource by using the TREE_CONNECT message. The mes‑

sage includes the name of the resource (server and share name) and, for earlier clients that do not perform logons, a shared password. The server responds by sending the user a value called the TID (Tree ID), which will be used in SMBs exchanged for this connection.

After the connection has been established, several basic SMB command formats can be used to manipulate files and directories that reside on the share. For example, the CREATE_DIRECTORY message is used to create a new directory in the file share's directory structure. The client passes the pathname for the new directory, and the server creates the directory, provided that the client has the appropriate access rights or permissions. The DELETE_DIRECTORY SMB message can be used to remove a directory, again based on the functions allowed for the username.

Opening and Closing Files

The OPEN message is used by a client to open a file. The path for the file is given, relative to the file share root. The client specifies the access that is desired, such as read, write, or share. If the file is successfully opened, the server returns a File ID (FID) to the client, which is used to further access the file using other SMB message types; it is similar to a file handle, which most programmers will recognize.

The server also returns data to the client indicating the actual access that was granted, which is read- only, write-only, or read/write. The CLOSE message is sent by the client to tell the server to release any locks held on the resource fileheld by the client. After this message, the client can no longer use the FID to access the file, but it must instead reopen the file and obtain a new value.

When a client does not know the exact name of a file that it wants to open, the SEARCH message can be used to perform a directory lookup. This function enables wildcards to be used, and the server response can include more than one filename that matches the request.

The File Transfer Protocol

Like the Telnet server, Windows NT/2000/2003/XP comes through Windows Server 2003, the FTP server is providedwith an FTP client. For Windows NT 4.0 by installing Internet Information Services

The FTP Client

The FTP client can be utilized easily from the Command Prompt and uses the standard syntax that's common to other FTP clients, with a few exceptions that you might not notice. For example, although many Unix/Linux servers require that you log in by using the command User , the Windows version prompts you for the username after you issue the FTP command as well as the password for the account name you enter. This is a minor difference, but it's important to note that although FTP is defined by a set of RFCs, some vendors add their own features to make the utility simpler to use.

The FTP server for Windows NT through Windows Server 2003 is a component of IIS, which is included as part of the installation procedure for Windows 2000. For Windows NT, you can use the icon that appears on the desktop of a Windows NT Server to install IIS or, better yet, download the newest version from Microsoft. IIS has been enhanced many times since its first release. Windows 2000 Server users will find that IIS is included on the server installation CD, but again, check for a newer version at Microsoft's Web site. An important reason for this is that newer versions have fixed problems with previous ones. Of course, the reverse is also true in some cases. One problem is fixed by a newer version, but might introduce a new set of problems!

Another method for logging into many sites is to use the username anonymous. The convention for using this login is to use your email address for the password prompt. After you've logged in to the FTP server, you can issue commands that are available on that server. For example, the commands is and dir will usually produce a listing of files and directories for the main directory that's set up for your login type. When using Unix/Linux or Windows clients, you can use the CD command to change to another directory until you find the data that you need to use. Notice that for most implementations of FTP, you must use lowercase characters for the commands and use the exact lowercase or uppercase syntax for a particular file. You can then use commands such as the following:

• get—Use this command to retrieve a file from a remote server. For example, get filename.
• put—Use this command to send a file to a remote server. For example, put filename.
• mget—This command can be used with wildcards (such as * and ?) to retrieve multiple files that match the wildcards.
• mput—This command works like mget, but enables you to send multiple files to the FTP server using wildcards.
• hash—If you care to watch the progress of an operation such as sending or receiving a file, this command will print hash marks (#) to show you the progress of the operation.
• binary/ascii—These commands specify the type of file you want to receive or send. ASCII files consist of simple text files, whereas binary files are usually executable files (application files, word processing files, and so on).
• prompt—This command might not be available on all implementations of FTP. This command is generally used with the mget or mput commands. When using these commands with wildcards, you might be prompted to specify yes or no (Y/N) before sending a file. The prompt command eliminates these prompts and just downloads or uploads all files matching the file specification.
• quit—This command is used to exit the FTP client.

Tip

Wildcards are used by many operating systems to indicate that you're specifying certain characters that a filename must contain and at the same time specifying that other characters can be anything. The asterisk (*) wildcard means that any characters (and any number of characters) can be substituted for the filename. For example, using the filename of Yoko*.txt will retrieve (or send) any file that starts with Yoko, ends with .txt, and contains any number of characters between Yoko and the dot 1.1 delimiter.

Another wildcard, the question mark (?) can be used to specify a specific number of characters that can be used to match a get or put operation. For example, the filename sec ret???.txt means that the file must start with the text secret and be followed by just three characters and the filename extension .txt. Contrast this with the * wildcard which allows for any number of characters following those you specify.

Additionally, you can specify the * wildcard in a manner such as *.mpeg2 to send or receive any file that ends with the file extension of . mpeg2, no matter how many characters make up the first part of the filename. The same goes for using the ? wildcard, although it still specifies that only filenames that contain the same number of question marks will be sent or retrieved

Communication with Clients

One of the first political stumbling blocks we encountered with our wire- frames in project A was their use in client discussions. Our aim in initial client meetings was to arrive at agreement about how the site would work in terms of navigation, and the kinds of content for each page such as photos, text, tables and so on. However, because of the apparently realistic content and dynamic behaviour, the client tended to focus on small details of content rather than broad views of the navigational and content structure - the very aspects on which we wanted feedback. For example, we put fictional prices with their products, and used fictional attributes to illustrate how real attributes would be displayed. While this approach saves time in developing prototypes, as real values do not have to be researched, the client latched on to these specific parts of the prototype asking questions such as "do we really sell them at that price" and "I didn't realize that product came in that colour". Constantly explaining the rough nature of the prototype meant that we concentrated on small details rather than discussing the overall nature of the proposed web-site.

In terms of our dimensions we would suggest that at this early stage of our ideas the prototype was too high in fidelity for the target audience (the clients). In retrospect, it would have been better to use rougher prototypes at this stage with the client, e.g. paper prototypes, or clickable paper-looking prototypes using a computer to show the navigational flow.

In Project B the wireframe worked relatively well as a communication tool with the client. It made it relatively easy to explain and discuss ideas of information structure and functionality with the client as the wire frame made it very concrete. The problem with the wireframe in Project B was that theclient thought the wire frame was close to the final site but for us it was not. This led to problems when communicated to the external graphic design agency (see Communicating with Graphic Designers). We had different interpretations of the fidelity of the wireframe which led to political tensions.