Data communication protocol

Data Communication Protocol {DATA COMMUNICATION PROTOCOL}

<p>This application claims priority to U.S. Provisional Application Serial No. 60/685,008, filed on May 25, 2005 and incorporated herein by reference. This application is assigned to the assignee of the present invention and is incorporated herein by reference, and is filed concurrently with the present application and is a pending agent case management number 5660/313764 "Data Communication Coordination Using a Sequence Number" with Sequence Numbers)".</p>

<p>Many of the data communication protocols still in use today, such as the Server Message Block (SMB) protocol, were developed at a time when computing resources were very different from today, for example, when network bandwidth was generally limited and memory was very valuable. As a result, when used in current networks, these protocols can limit overall performance. For example, since it was designed at a time when memory was limited, the buffer size is small and requires more round-trips to transfer large amounts of data.</p><p>Furthermore, the current SMB protocol has other limitations that become apparent over time. For example, the current SMB protocol is vulnerable to denial of service attacks, and the design of the protocol makes it difficult to resist these attacks. Likewise, the method for ensuring packet security is also difficult. Also, there is currently no mechanism for performing a quality service-like operation, for example, a trusted client obtains the same server resources as an untrusted client.</p><p>Various improvements or dialects of the SMB protocol have been developed over the years, but each variant is essentially a patch-based approach that adds some additional features by tweaking the various parts. Therefore, it is not easy to expand. In summary, while current SMB versions are still a frequently used and valuable protocol, they are less than ideal when used with current network resources.</p>

<solutionproblem><p>In summary, various aspects of the present invention relate to data communication protocols used by clients and servers for communication, such as file sharing. </p></solutionproblem><meansproblemsolution><p>The client sends a negotiation packet identifying the protocol dialect set that the client can interpret to the server. The packet is in a format that does not require another request, and a server that cannot communicate with the second data communication protocol will indicate that the first communication protocol should be used. If the server can communicate with the second data communication protocol, it will respond to that effect. The client will call a driver that handles communication with the server in the appropriate protocol indicated by the server. In one exemplary implementation, the second communication protocol is SMB 2.0 or higher.</p><p>Another aspect and enhancement of the protocol is that it can include a create command with additional context data appended, and a compound command comprising a plurality of related or unrelated commands. Another aspect and enhancement is the ability to transmit extended error data from a server in response to multi-channel commands associated with requests to transmit data on separate data channels, signature capability verification requests to ensure secure connections are established, and requests. include the ability to</p><p>Upon receiving the compound command, the server determines whether the compound command includes unrelated commands or related commands. If the compound request contains unrelated commands, each request is handled as a separate request, and if the compound request contains related commands, each request is handled sequentially. If the related command includes a create/open command, the server uses the file handle of the create/open command for each subsequent related command, eg, there is no need to wait for handling again from the client.</p></meansproblemsolution><effectiveness><p>A data communication protocol has been disclosed in which the server does not require the client to retry negotiation if the servers cannot accommodate the protocol requested by the client. As a result, the server does not require a waiting time for renegotiation, which is particularly advantageous in a complex network environment. In addition, the present invention enables verification of complex commands, data channels, and secure connections.</p><p>Other advantages will be apparent from the detailed description given below in conjunction with the drawings. </p></effectiveness>

<p><b><u>Exemplary operating environment</u></b></p><p>1 is an exemplary diagram of a suitable computing system environment 100 in which the present invention may be implemented. Computing system environment 100 is merely one example of a suitable computer environment and is not intended to suggest any limitation as to the scope of use or functionality of the present invention. Further, the computing environment 100 should not be construed as having any dependencies or requirements with respect to any one or combination of components depicted in the example operating environment 100 .</p><p>The invention is operational in many other general purpose or special purpose computing system environments or configurations. Personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessing systems, microprocessors, as examples of well-known computing systems, environments and/or configurations in which the present invention may be suitable for use. - a distributed computing environment comprising infrastructure systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, any of the above systems or devices; one of the dialects of network equipment such as a print server or a printer itself, and a NAS storage device, but is not limited thereto.</p><p>The invention may be executed on a computer if described in the general context of computer-executable instructions, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located on local and/or remote computer storage media including memory storage devices.</p><p>Referring to FIG. 1 , an exemplary system for implementing the present invention includes a general purpose computing device in the form of a computer 110 . Components of computer 110 include, but are not limited to, processing unit 120 , system memory 130 , and system bus 121 connecting various system components to the processing unit, including but not limited to system memory. The system bus 121 may be any of a number of types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. Examples of such structures include Peripheral Component Interconnect (PCI), also known as Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Mezzanine bus. bus, but is not limited thereto.</p><p>Computer 110 generally includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 110 and includes both volatile and non-volatile media, removable and non-removable media. Examples of computer-readable media include, but are not limited to, computer storage media and communication media. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in a method or technology for storage of any information, such as computer readable instructions, data structures, or other data. Computer storage media are RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVD or other optical disk storage device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device or for storing the desired information. any other medium that can be used and accessed by the computer 110 , but is not limited thereto. Communication media are typically embodied in computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier WAV or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal comprising one or more sets of its characteristics or a signal modified in such a way as to encode information within the signal. Examples of communication media include, but are not limited to, wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, FR, infrared, and other wireless media. Also, any combination of the above should be included within the scope of computer-readable media.</p><p>System memory 130 includes computer storage media in the form of volatile and/or non-volatile memory such as ROM 131 and RAM 132 . A basic input/output system (BIOS) 133, including basic routines that assists in transferring information between elements within computer 110, such as during startup, is typically stored in ROM 131. RAM 132 generally contains data and/or program modules that are readily accessible and/or currently being operated on by processing unit 120 . For example, an operating system 134 , an application program 135 , other program modules 136 , and program data 137 are illustrated in FIG. 1 , but the present invention is not limited thereto.</p><p>Computer 110 may also include other removable/removable/removable volatile/non-volatile computer storage media. By way of example only, a hard disk drive 141 that reads from or writes to a fixed, non-volatile magnetic medium and a magnetic disk drive 151 that reads from or writes to a removable, non-volatile magnetic disk 152 in FIG. ) and an optical disc drive 155 that reads from or writes to a removable, non-volatile optical disc 156, such as a CD ROM or other optical medium. Other removable/removable/removable/non-volatile computer storage media that may be used in the exemplary operating environment include magnetic tape cassettes, flash memory cards, DVDs, digital video tapes, solid state RAM, solid state ROM, and the like. may, but is not limited thereto. Hard disk drive 141 is generally connected to system bus 121 through a fixed memory interface, such as interface 140 , and magnetic disk drive 151 and optical disk drive 155 are generally connected to system bus 121 , such as interface 150 . It is connected to the system bus 121 by a removable memory interface.</p><p>The drive shown in FIG. 1 and described above and its associated computer storage medium provide storage of computer readable instructions, data structures, program modules, and other data for the computer 110 . For example, in FIG. 1 , hard disk drive 141 is shown to store an operating system 144 , application programs 145 , other program modules 146 , and program data 147 . Note that these components may be the same as, or different from, the operating system 134 , application programs 135 , other program modules 136 and program data 137 . Operating system 144 , application programs 145 , other program modules 146 , and program data 147 are, at a minimum, numbered herein differently to illustrate that they are separate copies. A user may use a computer (via input device) such as a tablet or electronic digitizer 164, a microphone 163, a keyboard 162, and a pointing device 161 commonly referred to as a mouse, trackball or touchpad. 110) to input commands and information. Other input devices, not shown in FIG. 1 , may include a joystick, game pad, satellite dish or scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 coupled to a system bus, but by other interfaces and bus structures such as parallel ports, game ports, or universal serial bus (USB). it might be A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190 . The monitor 191 may also be integrated with a touch screen panel or the like. It should be noted that the monitor and/or touch screen panel may be coupled unrestrictedly into a housing in which the computing device 110 is integrated, such as in a personal computer of the tablet type. A computer, such as computing device 110 , may also include other peripheral output devices, such as speakers 195 and printer 196 , which may be connected via an output peripheral interface 190 , or the like.</p><p>Computer 110 may operate in a network environment that is logically connected to one or more remote computers, such as remote computer 180 . Remote computer 180 may be a personal computer, handheld device, server, router, network PC, peer device, or other common network node, although in FIG. 1 memory storage device 181 Although only shown, it generally includes all or many of the elements described above with respect to computer 110 . The logical connections shown in FIG. 1 include a LAN 171 and a wide area network (WAN) 173, but may include other networks as well. Such network environments are common in offices, computer networks in corporate areas, intranets, and the Internet.</p><p>When used in a LAN network environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170 . When used in a WAN network environment, computer 110 typically includes a modem 172 or other means for establishing communications over WAN 173, such as the Internet. Modem 172 may be internal or external, and may be connected to system bus 121 through user input interface 160 or other suitable mechanism. In a networked environment, program modules depicted relative to computer 110 or portions thereof may be stored in remote memory storage devices. By way of example, but not limitation, FIG. 1 shows a remote application program 185 residing on a memory device 181 . It will be appreciated that the network connections shown are exemplary and other means for establishing a communication link between the computers may be used.</p><p><b><u>data communication protocol</u></b></p><p>Various aspects of the technology described herein relate to a data communication protocol, such as a newer version (2.x or higher) of the SMB protocol. In one example implementation generally described herein, the SMB protocol is used for file data transfer. However, as can be readily understood, the present invention is not limited to file data, any specific implementation or example described herein. Instead, various methods of implementing the present invention may be implemented, including those used to communicate with printers, named data pipes, and general devices, and the like. Thus, the present invention is not limited to any particular file-based example used herein, but rather may be used in a variety of ways that provide advantages and effects in general computing.</p><p> Various other aspects of the technology described herein relate to new versions of SMB over which file-server interactions can be built. As is understood, a more lightweight protocol that supports existing functions (up-level) is provided, and this protocol is scalable, so it is easier to update with new features.</p><p>Turning now to FIG. 2 , shown is a block diagram illustrating an exemplary networking environment in which a client 202 and a server 204 communicate via one or more communication channels. Although the functions and components of client machine 202 and server 204 are shown as being located in two separate computers, such as main computer system 110 and remote computer system 180 of FIG. A component or function performed thereby may be provided on one machine or distributed across multiple computers.</p><p>Network file system commands of the application program 206 are handled by a client redirector component 208 , which communicates with a counterpart common network module (SRVNET) 210 to provide a file system 212 . execute the command on Before these commands are processed, a communication protocol agreed upon by the client and server is negotiated, usually a newer version/dial that both can interpret.</p><p>In general, as shown in Figure 3, after the client 202 establishes a connection, it negotiates with the server 204 to ultimately prepare a session. Although the client can directly indicate to the server that it is an SMB 2.x client (where the number 2.x stands for any new version when compared to an existing SMB 1.x version), the client is backwards-compatible. -compatible) can also be negotiated through a negotiation packet. In this way, a client can only communicate with an SMB 1.x capable server, but can communicate without initiating a separate connection if an attempt to negotiate at a higher level fails. At the same time, the code for implementing each protocol can be packaged into each independent driver.</p><p>In one example implementation, the client SMB engine component 220 provides the packet to a server (eg, server) 204 , indicating that the client 202 is negotiating at least in an SMB 1.0 session. For a client 202 speaking both the SMB 1 dialect and the new SMB 2 protocol revision, the client may send a conventional SMB 1 shape packet, but this packet is in fact an indication indicating that it is requesting SMB 2.x if possible. further includes The SMB 2-capable server will detect this request and respond with an SMB 2 negotiate response. More specifically, to indicate that the client 202 is SMB 2.x capable, the SMB 1.0 negotiation packet contains a set of dialect strings, one of which is the client's SMB 2.x communication capability. indicate that it is possible</p><p>Accordingly, the client 202 sends an initial negotiate containing the revision number it supports. The current revision is 0, ie SMB 2.0, and future clients may claim to support any subset of Dialect revisions.</p><p>When the server 204 receives the packet, it will respond based on its capabilities. The server 204 will respond with an SMB 1.0 negotiation response along with any 1.x dialect information, or if SMB 2.x communication is possible, it will respond with an SMB 2.0 negotiation response. A specific SMB dialect revision matching one of the dialect strings may be returned, usually the largest numbered version of the dialect revision that the client 202 can handle that the server 204 can handle.</p><p>To this end, once the server 204 knows which dialect revisions the client 202 is talking about, it compares them to the revisions that the server 204 can interpret, and compares them to the preferred common dialect revision (usually the largest). number) is returned. For example, if the server supports dialects (1-8), but the client only supports 1, 2 and 4, the server will return 4. This gives the client 202 a clear understanding of the kinds of commands it can send to the server 204 . To select which dialect to use, the SRVNET module 210 sends its SMB feeders 222 in order from highest to lowest version/dialect.<sb>1</sb>-222<sb>m</sb>) essentially starts the negotiation by forwarding the packet to each, which continues until one SMB provider agrees to handle this communication session based on the packet content. Eventually communications on this connection are routed to that provider, in this example the SMB 2.0 feeder 222<sb>m</sb>am.</p><p>At the client end, the SMB engine component 220 receives the response, and when communicating with the server based on the version/direct information in the response, any client SMB component 224<sb>1</sb>-224<sb>n</sb>) will be used. In this way, the client 202 and the server 204 both agree on which SMB dialect to use in a given session. The client has a plurality of SMB components 224, each of which is a different version/dialect.<sb>1</sb>-224<sb>n</sb>), for example, a client can communicate with one server via SMB 1.x and at the same time communicate with another server via SMB 2.x.</p><p>The server 204 may return other information to the client 202 including a security mode indicating whether the server 204 requires a security signature. Note that if the security signature is enabled, but the first few packets (eg capability negotiation) are plaintext, an attacker can force the client to a lower level where the attacker is aware of the vulnerability.</p><p>A secure connection works by providing another capability verification exchange that is signed (regardless of whether the signature is enabled or not). 7 shows a request/response after session preparation. Other information, such as an IP address, may be included in the packet so that the server can verify its response and not other entities. If IPSEC or any other form of network security is enabled, the signature may be turned off.</p><p>The server 204 may return capability bits for the server, such as whether the server is aware of the Distributed File System (DFS) and is capable of Lightweight IO (LWIO). The client 202 discards any capability bits that it cannot interpret, which may occur if the server 204 has a newer version than the client's corresponding version. Other information that may be returned in the negotiation exchange is the server's unique ID, the maximum read/write size that the server will accept, data offset hints for high-speed write processing, the current server's system time, and what is used as a seed of security in the extended security case. Contains security information.</p><p>Session preparation handles the authentication process for a new session, which can be multiple exchange events. The client 202 sends a first session preparation by querying the local security system for a security blob to be transmitted over the network, filling in the capability, maximum size field, and VcNumber to be described later. Server 204 receives this blob and passes it to the security system. If the server 204 determines that more information is needed, it will return its security blob with an error code (STATUS_MORE_PROCESSING_REQUIRED). The client 202 passes this blob back to the local security system, and the process will repeat until a failure occurs or authentication is successful.</p><p>VcNumber indicates to server 204 if there are other connections established from this same client 202 . If it is zero, the server 204 will consider no other connections made from this client and will drop (deem inappropriate) any such connections it finds. If VcNumber is 1 or greater, server 204 will not drop any existing connections.</p><p>The channel indicates to the server 204 whether this client 202 is attempting to establish another connection with an existing session. A session may be identified by the user/computer pair that sent this session preparation. Channels share the same TreeId/UserID/ProcessID/FileId information. For channel authentication, the authentication blob may be an encrypted challenge-response over a first channel and sent back over a second channel to allow the client 202 and server 204 to mutually authenticate each other. can If the response is successful, the server 204 will also notify the client 202 that it has been authenticated as applicable, either as a guest, or as a null user.</p><p>Once the session is ready, the client 202 can perform data transfers, file locking and directory related operations using various commands described below, including create, read, write, and close. In the above-mentioned "controlling data communication using sequence number" patent application, when using these commands, the server can control the use of server resources by the client. Additionally, the protocol offers a number of efficiency improvements regarding how and what information is conveyed.</p><p>As generally shown in Figure 4, the create command has been extended to allow attachment of context information; In general, the context information includes any additional creation parameters that are tagged in the create command. For example, a transaction identifier may be appended to a transaction file system-related create command. As long as the server can interpret the additional context information, the server can be informed of the extended information (note that the server will ignore additional information it cannot interpret), and can return context-related information. As can be easily understood, this essentially provides built-in extensibility by providing additional functionality without changing the protocol.</p><p>The command ID and dialect revision number are provided in the new SMB headers disclosed below. The header has USHORT as a command field as opposed to UCHAR; By using the first byte of this USHORT to indicate a dialect, the command table is well-defined for existing commands, leaving much of the command table empty for future expansion. In general, a client may maintain a table containing pointers to functions that issue a given command for each dialect. For a client supporting a single dialect, the table would look like this:</p><p><table><tgroup cols="2"><colspec align="justify" colname="col1" colnum="1" colwidth="1705" /><colspec align="justify" colname="col2" colnum="2" colwidth="2614" /><tbody><row><entry align="justify" colname="col1"><b>Command</b></entry><entry align="justify" colname="col2"><b>Dialect</b><b> #1</b></entry></row><row><entry align="justify" colname="col1">produce</entry><entry align="justify" colname="col2">SmbCreate1</entry></row><row><entry align="justify" colname="col1">reading</entry><entry align="justify" colname="col2">SmbRead1</entry></row><row><entry align="justify" colname="col1">record</entry><entry align="justify" colname="col2">SmbWrite1</entry></row><row><entry align="justify" colname="col1">close</entry><entry align="justify" colname="col2">SmbClose1</entry></row></tbody></tgroup></table></p><p>For caching of functions, more information can be retrieved from the file on the closure. Therefore, to support this new function, a new close command is provided. The following client supports two dialects, and the table is as follows.</p><p><table><tgroup cols="3"><colspec align="justify" colname="col1" colnum="1" colwidth="1640" /><colspec align="justify" colname="col2" colnum="2" colwidth="2328" /><colspec align="justify" colname="col3" colnum="3" colwidth="2353" /><tbody><row><entry align="justify" colname="col1"><b>Command</b></entry><entry align="justify" colname="col2"><b>Dialect</b><b> #2</b></entry><entry align="justify" colname="col3"><b>Dialect</b><b> #1</b></entry></row><row><entry align="justify" colname="col1">produce</entry><entry align="justify" colname="col2">SmbCreate1</entry><entry align="justify" colname="col3">SmbCreate1</entry></row><row><entry align="justify" colname="col1">reading</entry><entry align="justify" colname="col2">SmbRead1</entry><entry align="justify" colname="col3">SmbRead1</entry></row><row><entry align="justify" colname="col1">record</entry><entry align="justify" colname="col2">SmbWrite1</entry><entry align="justify" colname="col3">SmbWrite1</entry></row><row><entry align="justify" colname="col1">close</entry><entry align="justify" colname="col2">SmbClose2</entry><entry align="justify" colname="col3">SmbClose1</entry></row></tbody></tgroup></table></p><p>Note that most of the listed functions are identical except for the changed close command. The client can now talk to Dialect 2 servers and use the new functionality, while still using the old functionality for Dialect 1 servers. Nothing has changed in communicating with the Dialect 1 server.</p><p>As technology advances, new network hardware that can perform relatively much larger reads and writes becomes available. Dialect #3 is available for these releases, and the table expands to:</p><p><table><tgroup cols="4"><colspec align="left" colname="col1" colnum="1" colwidth="1755" /><colspec align="left" colname="col2" colnum="2" colwidth="2419" /><colspec align="left" colname="col3" colnum="3" colwidth="2287" /><colspec align="left" colname="col4" colnum="4" colwidth="2172" /><tbody><row><entry align="left" colname="col1"><b>Command</b></entry><entry align="left" colname="col2"><b>Dialect</b><b> #3</b></entry><entry align="left" colname="col3"><b>Dialect</b><b> #2</b></entry><entry align="left" colname="col4"><b>Dialect</b><b> #1</b></entry></row><row><entry align="left" colname="col1">produce</entry><entry align="left" colname="col2">SmbCreate1</entry><entry align="left" colname="col3">SmbCreate1</entry><entry align="left" colname="col4">SmbCreate1</entry></row><row><entry align="left" colname="col1">reading</entry><entry align="left" colname="col2">SmbRead3</entry><entry align="left" colname="col3">SmbRead1</entry><entry align="left" colname="col4">SmbRead1</entry></row><row><entry align="left" colname="col1">record</entry><entry align="left" colname="col2">SmbWrite3</entry><entry align="left" colname="col3">SmbWrite1</entry><entry align="left" colname="col4">SmbWrite1</entry></row><row><entry align="left" colname="col1">close</entry><entry align="left" colname="col2">SmbClose2</entry><entry align="left" colname="col3">SmbClose2</entry><entry align="left" colname="col4">SmbClose1</entry></row></tbody></tgroup></table></p><p>A client with such a table can speak three dialects, and will take advantage of the features available in each dialect. A certain advantage of using this method is that each SMB command can be mapped back to the dialect that submitted it, since the commands are (dial|commands). This helps determine which server supports which when a command is submitted. If the function for a given command has not changed in the new dialect, the code is not changed. When a function is changed, the low-level interface code is not changed, but new code is added to support the new function.</p><p>On the server side, the server dispatch table is a double switch between (dial) and (command). This allows for logical separation of new functionality within the code, making it easier to interpret and change.</p><p>Looking at one aspect of the protocol that provides efficiency, multiple commands can be compounded into a single packet (or fewer packets than commands). Accordingly, complex operations can be performed in a manner that reduces the number of exchanges between the client 202 and the server 204 . For example, the compound request packet may include commands to create/open a file, a command to write to a file, and a command to read from a file. Thus, a compound performs operations on related operations (eg, the same file handle) and also combines unrelated operations.</p><p>An example of a complex related request is shown generally in FIG. 5 , where a single request (as opposed to eg FIG. 4 ) can handle reads and writes by providing parameters that would be appropriate. As shown in FIG. 5 , a single request may receive a composite response and/or separate responses, eg, depending on when it ends. More complex requests such as create/open, read, write and close can be made into a single request. This is done by marking the packet as having relevant actions; The server will know that the file handle it receives following create/open applies to other commands in the compound request. Note, however, that related complex requests are handled in the order they are packaged, so it is up to the client to verify that the order is correct before sending.</p><p>Compositing in SMB 2 is simpler than the existing complex rules in SMB 1. To this end, SMB2_HEADER includes "NextOffset" used to identify an offset from the header of the current command to the header of the next command (details will be described later). Each command has its own SMB2_HEADER containing a separate MessageId. As shown in FIG. 5 , the server response or responses may come as a single composite response or as separate responses. In case of failure, the response will be the same as in the case of any other failed command.</p><p>For unrelated messages, the command will always be treated as if they were received separately. This allows a resetter or intermediary component to automatically composite unrelated packets. Delay can be used to obtain packets to be compounded, especially if the delay time is relatively less than the exchange time. Since the server treats received packets separately, there is no need to make modifications to resolve unrelated complex requests that would otherwise be needed. However, the entity performing the compounding may need to separate any compound responses, since otherwise the server may combine the separate responses.</p><p>The associative mode allows the client to send a sequence of commands to be executed, where the result of one command is potentially used in the next command. These commands share the same Session/Process/Tree/File ID and will be executed sequentially, stopping processing on the first error. If there are other commands to proceed after failure, the operations immediately stop processing with STATUS_NOT_PROCESSED. An example of how this can be used is to pair session preparation with tree connections. If session establishment fails, a tree connection will never be attempted, and the process will stop with STATUS_NOT_PROCESSED. If session preparation is successful, tree connection is made using the SessionID of the session preparation command. The same method can be used to execute Create followed by QueryFileInformation or create-read-close set.</p><p>Conditional and implied complexes can also be implemented. For example, conditional compound commands such as open and read if the file is less than 64 KB can be sent, so that after opening in one exchange, small files can be automatically acquired or large files can only be opened. It is possible to reduce the number of nested complexity exchanges, such as automatically returning directory enumeration data in response to a directory open request even when not explicitly requested. The benefits and advantages of using this enhanced composite are greater in high latency networks.</p><p>Another way to improve efficiency in the protocol is to use multiple channel communication. A transport connection for commands may be used between the client and server, where one command specifies an alternate channel for streaming data. For example, a read request may specify an offset and length as well as an alternative channel from which to read data; Record requests work similarly. 6 shows an example of a 1 GB read request starting at offset (0) and requesting to stream data to data channel (5).</p><p>Streaming data over an alternative channel has a number of advantages, including the need to include and process packet headers. The client does not need to replicate from one buffer to another as in the conventional single-channel communication by pre-posting the buffer and streaming the data therein. Fairness is another advantage, e.g. one request on the control channel does not have to wait until the transfer of a large amount of data (e.g. 5 GB) is finished before the request is handled, because 5 GB goes through the data channel. because it will</p><p>Multiple NICs are becoming increasingly common, and the protocol uses any available network bandwidth. This involves working with multiple connections to the same session, regardless of the transport (or NIC) on which the connections are established. Specific hardware may be employed.</p><p>Thus, a session with SMB 2.x is not tied to a connection. Instead, a plurality of "channels" may be established through separate physical connections. Sessions can exist on each of these connections, and IDs used to refer to files and processes are common across channels. This makes it possible to have regular channels for namespace operation and creation, while using specific network hardware for reading and writing when available. Also, small network glitches may not lead to data loss, because as long as one channel is opening a session, the session remains active. Various implementation details are described herein with reference to session preparation commands and read/write commands.</p><p>As an example, consider a client that establishes a connection to a server over an enterprise's public network with simple TCP. This is the first connection and therefore always channel (0). Upon sensing that both sides have a private network for data transfer (eg if each has a gigabit card), the client and server can establish a second connection as channel 1 via this card. While the client is browsing a given file, a directory query is being sent over channel (0) and data is being sent over channel (1). When a client wants to browse certain directories encrypted on the server, when the client requests data, the resetter recognizes that the data is sensitive and sends it to the server on a new channel with IP Sec active ( Channel; 2) is established. When a client requests confidential data, it will request that less confidential data continue to come on channel 1 (since channel 1 is faster), while confidential data is transmitted on channel 2 .</p><p>As can be readily understood, there are significant advantages by simply providing bandwidth gains while also providing opportunities for QoS and security improvements. Note that when reading/writing a channel, the server/client can prepare the receive buffer before any data read, so that the mechanism does not need to replicate data movement, thereby further improving server/client scalability.</p><p>Also, SMB error packets are allowed to be tagged with any data. Thus, a description of why it failed is provided, which can be very valuable. An example of tagging that provides useful information to a client along with arbitrary data is the symbolic link evaluation shown generally in FIG. 8 . In essence, a client-created request can fail by requesting a path that is in fact a symbolic link to another path. Instead of simply failing the request, by providing a new path, the client can change to a reparse path, which will ultimately succeed; Note that iteration through multiple requests may be necessary to find a successful path.</p><p><b><u>Example protocol definitions</u></b></p><p>The new header is a 64-byte structure (eg, twice the size of the current structure).</p><p><img file="KR101036751B1_D0001.tif" /></p><p><img file="KR101036751B1_D0002.tif" /></p><p>Protocol is simply a protocol identifier for identifying a packet. In existing SMB implementations this consists of {0xFF, 'S', 'M', 'B'}. For the new protocol, this consists of {0xFE, 'S', 'M', 'B'}.</p><p>StructureSize identifies the size of the SMB2_HEADER structure and will be used to indicate the sub-decimal version within the header itself if other changes are introduced later. </p><p>Epoch represents the "version count" of the server. This is incremented each time the server is cycled (or when the server service is stopped and then started) to indicate to the client whether the state was maintained while the server was blocked. This will be used in future ongoing handling and can be considered "Reserved" for the time being.</p><p>Status indicates the error status for a given operation as in the existing SMB implementation.</p><p>Command identifies the command for the packet as described herein. </p><p>CreditsGranted/CreditsRequested, as described in a related patent application entitled "Corresponding Data Communication Using Sequence Numbers", occurs when a client sends a request for more credit, and when a server sends a new credit management technique for more credit. It is used in response to grant permission.</p><p>Flags </p><p><img file="KR101036751B1_D0003.tif" /></p><p>It is associated with a message containing the flags, if present, indicating that this message is a response as opposed to a request.</p><p><img file="KR101036751B1_D0004.tif" /></p><p>In response, the server returns STATUS_PENDING with this flag set to indicate that it is processing the request asynchronously.</p><p><img file="KR101036751B1_D0005.tif" /></p><p>is set to indicate that operations are relevant when sending the client's compound message, so that the file opened in creation is used as the FileId for subsequent operations.</p><p><img file="KR101036751B1_D0006.tif" /></p><p>is set when the packet is signed. The receiver must verify the signature. The key used for signing is based on the session that sent the packet.</p><p><img file="KR101036751B1_D0007.tif" /></p><p>This is a DFS operation. The server must allow DFS to munge the name. This can be replaced with a create selection.</p><p>MessageId identifies the message being sent in response.</p><p>ProcessId describes the client-side identification of the process issuing the command.</p><p>SessionId identifies the session established for the command, or 0 if no session is in use.</p><p>TreeId identifies a tree connection for the command, or 0 if no tree connection is in use.</p><p>AsyncId: As described in a related patent application entitled "Data Communication Coordination Using Sequence Numbers", message IDs are effectively sequence numbers, and the window of available sequence numbers is always set to slide right. An instruction to be executed for too long (named pipe reads or change-notifications, creations pending on an oplock break, anything that can block indefinitely) can freeze the window's ability to slide. have. To solve this problem, the server can optionally respond to any command with STATUS_PENDING, set the SMB2_FLAGS_ASYNC_COMMAND flag described above, and provide a unique identifier on behalf of Session/Tree/ProcessId. This means that the client can continue sliding the window as if it had received a response. After some time, the actual response will come with a matching AsyncId (and CommandId) to satisfy the request. When the client wants to cancel this command, the client sends a cancel with the set flag and matching AsyncId.</p><p>The security signature is the same as in the previous protocol, except that there are no more hidden index numbers. Indexes do not necessarily use sequence numbers for MIDs (this directly prevents replayability). This allows the use of secure signatures without sequencing operations during transmission.</p><p>NextCommand indicates the offset from the beginning of this header to the next command in the message. Messages must be quad-aligned. SMB2_FLAGS_RELATED_COMMAND is used to enable various combinations as described above.</p><p><b>command format</b></p><p><b><i>Negotiation</i></b></p><p>As discussed above, the client and server exchange negotiation requests and responses as part of a handshake that helps determine each other's capabilities. </p><p><b>format</b></p><p><img file="KR101036751B1_D0008.tif" /></p><p><img file="KR101036751B1_D0009.tif" /></p><p><b><i>Session Preparation</i></b></p><p>As described above, session preparation handles the authentication process for a new session.</p><p><b>format</b></p><p><img file="KR101036751B1_D0010.tif" /></p><p><b><i>log off</i></b></p><p>Log off the existing session.</p><p><b>format</b></p><p><img file="KR101036751B1_D0011.tif" /></p><p>This command rips the session with the SessionId specified in the header. Opened files are closed, and other existing structures (tree connections, etc.) are torn. No further operations can be performed for the given SessionId.</p><p><b><i>tree access</i></b></p><p>Create a tree connection to a shared resource on the server machine.</p><p><b>format</b></p><p><img file="KR101036751B1_D0012.tif" /></p><p><img file="KR101036751B1_D0013.tif" /></p><p>The client issues this command to the server to establish a tree connection. the path is<img file="KR101036751B1_D0014.tif" />, and fills the buffer. Features such as sharing scoping are possible by including the name of the server.</p><p>If the response from the server is successful, the client receives the TreeId in the header with ShareFlags and ShareCapabilities. Currently, ShareFlags indicate to the client which CSC caching characteristics are for sharing, but more may be added in the future. ShareCapabilities indicates to the client whether the file system that supports sharing supports file-level security, timewarp, transactional file system (TxF), or client-side encryption. If the filesystem supports these properties on some but not all subtrees (such as the mount part), the filesystem supports these properties, but each request to use these properties if not allowed will just fail. Should be. Clients MUST ignore any flags or capabilities that they cannot interpret.</p><p><b><i>tree block</i></b></p><p>Tear the existing tree connection.</p><p><b>format</b></p><p><img file="KR101036751B1_D0015.tif" /></p><p>Once this command has been processed, further operations on the given TreeId may not terminate successfully. The TreeId is taken from the header.</p><p><b><i>produce</i></b></p><p>Open a file, printer, or pipe.</p><p><b>format</b></p><p><img file="KR101036751B1_D0016.tif" /></p><p><img file="KR101036751B1_D0017.tif" /></p><p>The create request is a variable length request, which enables the creation of a file with various attributes as well as conventional well-defined attributes. The canonical case (no extended attributes) is obvious; The client fills in the RootDirectoryFid (for relative open if desired), DesiredAccess, FileAttributes, ShareAccess, CreateDisposition and CreateOptions. They set the desired opilock level, and write the SecurityFlag and Impersonaton levels for QoS. Currently, SmbCreateFlags is not defined, but space is allocated for use. When the client sends this packet to the server, the server opens the file and returns a failure code, or returns success with FileId, Creation/LastAccess/LastWrite/LastChangeTime, AllocationSize and EndOfFile information identifying the file, and FileAttributes .</p><p>This is the same standard case as the current protocol works. As a more advanced case, consider a case where a user wants to create a file with extended attributes (EAs). In the previous protocol, this was handled in a completely different way through a transaction call. Now, the client can build a create request as standard, and can append a CreateContext to the end of the create request. The request has the name "ExtA" and the data will contain the EAs to be set on the file. When the server receives it, it will parse out the EA data and publish it with the creation. In response to the creation, CreateContext may also be returned to provide additional information. In one iteration, the names have length (4) so we can format them as longs and switch. The current list of CreateContext is:</p><p>1) "ExtA" - data contains extended attributes to be added on the created file.</p><p>2) "SecD" - data contains a self-relative security descriptor to be appended on the created file. </p><p>3) "TWrp" - The data contains a timewarp timestamp that should be used to find the file to open. The timestamp has a system time format.</p><p>4) "MrTx" - Data contains marshalled transactions to be used when opening a file as a transaction.</p><p>5) "MnVr" - The data contains the mini-version number (ULONG) for opening the traded file.</p><p>6)"Vers" - The data includes the version number (ULONG) of the opened file (creation response).</p><p>7)"NFid" - The data contains the NTFS Fid (LARGE_INTEGER) of the opened file (creation response).</p><p>8) "$Efs" - The data contains the $EFS stream to be stamped onto the newly encrypted file.</p><p>9) 'CSEl' - Data contains $EFS stream of open encrypted file (creation response).</p><p>Additional CreateContext values may be added as the servers support them (as values are added, they may have server-specific capability bits or associated with new dialect revisions so that the client can issue a create request) You can see which tags the server supports before). A server that receives a create request with an unrecognized context tag will treat the request as a failure.</p><p><b><i>close</i></b></p><p>The client sends close to close the previously opened instance of the file. Once closed, no file operations are allowed for the previous FID.</p><p><b>format</b></p><p><img file="KR101036751B1_D0018.tif" /></p><p>For a close command, the client specifies the FileID of the closed file along with LastWriteTime (in SystemTime format). This allows the client to set the last time a cached write was performed to that file as the last write time for that file. The client may also indicate that it does not want to specify a 1 by sending a 0 for LastWriteTime. This structure also allocates space for the Close flag, which is not currently defined but may be used later.<b></b></p><p><b><i>FLUSH</i></b></p><p>The flush command tells the server to flush all cached data on a given file.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0019.tif" /></p><p>Upon a successful response from the server, the client is guaranteed that all cached data has been flushed to its secondary persistent storage. The client specifies the FileId of the file it wants to flush. A flush on a pipe will not reappear for a while until the entire data on that pipe is exhausted.</p><p><b><i>reading</i></b></p><p>Read data from an open file.</p><p><b>format</b></p><p><img file="KR101036751B1_D0020.tif" /></p><p><img file="KR101036751B1_D0021.tif" /></p><p>Reading is very self-explanatory. The client specifies (via FileId) the file, offset and read length, and the server returns the data. There are several other things the client can specify. MinCount tells the server the minimum amount to read from the file for a successful return. If the read runs out, the server will simply return a failure instead of returning the entire data buffer. The client can also recommend Padding for better handling. This is the offset into the read response packet where the server should put the data. This allows the client to put the read response buffers in a more efficient state when receiving information in transit. The remaining field tells the server how much the entire read is for if it is only one section of the read. So, if a client wants to read 8K in chunks of 1K, it will issue a read for 1K with Remaining = 7K. This allows the server the option to optimize by reading the entire 8K in one operation and buffering that data back to the client.</p><p>In response from the server, it indicates how much data it returns (in the DataLength field) with the DataRemaining specified in the read command. </p><p>If the channel specified in the command is not the channel the command came from, the user requests a channel read. This means that when I request a read by "channel=1" and "Length=0, Remaining=64K" on channel 0, the server responds with "DataLength=0, DataRemaining=64K" and means that the next 64K bytes coming through Channel1 will be data. The client is responsible for synchronizing it to ensure that no data is pending on channel 1 when this command is issued. The client could also have issued (on channel 0) "Read Channel=1, DataLength=1K, Remaining=7k", so that the response will contain the first 1K of data and the rest of that data (the last 7K) of the channel will be streamed through 1.<b><i></i></b></p><p><b><i>record</i></b></p><p>Write data to an open file.</p><p><b>format</b></p><p><img file="KR101036751B1_D0022.tif" /></p><p>The client fills in the file (specified by FileId), offset and record length, and appends the data. It is recommended that the data returned as the original negotiation response be padded to aid server performance. The client can also tell the server how much more data to log, allowing the server to optimize. In response, the server indicates how much has been written and returns the expected amount in the future.</p><p>If the channel designated as a record is not the channel on which the command came, the client requests to stream data on another channel. A record received with "Channel=1, Length=0, Remaining=64K" on channel 0 is an example. The client is requesting to stream a 64K record on channel 1 . The server will respond with "Count=0, Remaining=64K" to allow the record. The response will contain the AsyncID for the second response to come after the data has been sent and acked on the channel. Then the next 64K bytes streamed on channel 1 will be the data. (no headers). Upon completion, unless a particular channel has a unique grant (in which case a unique grant will occur on that channel itself), the server will send SMB2_RESP_WRITE on channel 0 to indicate the success/failure of the operation and use the AsyncId information. will send the second response. </p><p><b><i>brake_</i></b><b><i>opilocke</i></b></p><p>Used to request and grant the release of opportunistic locks placed on a file. </p><p><b>format</b></p><p><img file="KR101036751B1_D0023.tif" /></p><p>When another user requests access to a file for which the client holds an opportunity lock, in a way that requests a break of that existing lock, the SRV will send the client SMB2_RESP_BREAK_OPLOCK. Then, the client should send a REQ_BREAK_OPLOCK to release the oplock for the given file, and the SRV will respond again acknowledging it.</p><p><b><i>lock</i></b></p><p>Used to request byte-range locks, and also used to request opportunity locks (and notify the client when one has broken).<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0024.tif" /></p><p>The syntax for the LOCK request is similar to the SMB1 lock request. The client specifies a FileId, and one or more SMB_LOCK structures indicating the length and offset it wants to lock. All of these LOCK structures must be either locks or unlocks. However, it is also possible to mix shared and exclusive lock requests in one batched lock operation. The most common use for lock batching would be to claim a series of locks as part of a batch op-lock break, most useful when you are certain that all locks will succeed.<b><i></i></b></p><p>A successful return informs the client that it has achieved (or released) the requested byte range lock. If it fails, the byte range lock is not allowed.<b><i></i></b></p><p><b><i>ECHO</i></b></p><p>The echo is used by the client to determine whether the server is still at a given point in time. Upon receiving this command, the server will just look around itself and return success.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0025.tif" /></p><p>The server responds to the packet to indicate that it is operating properly. Used to allow clients to "ping" the server.<b><i></i></b></p><p><b><i>CANCEL</i></b></p><p>Used by the client to request cancellation of a sent action. </p><p><b>format</b></p><p><img file="KR101036751B1_D0026.tif" /></p><p>Cancel has no response, but the command itself must either complete successfully or fail with STATUS_CANCELLED, which should happen as soon as possible. The action being sent is identified because it will share the MessageId of the cancel command. This is one case where the MessageId sent to the server may have already been used before. If the response arrives with an AsyncId, it should be present in the header and will be used to place the command on the server.<b><i></i></b></p><p><b><i>IOCTL</i></b></p><p>Ioctl is used to issue Device Control or File System Control commands across the network.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0027.tif" /></p><p><img file="KR101036751B1_D0028.tif" /></p><p>IOCTL is used to issue generic file system or device control commands across the network. It packs input and output buffers based on the method (METHOD) in the control code and sends them across the network. The server side then repackages them and issues FSCTL/IOCTL for the file object. The result is likewise packed and returned to the user with a status code. The allowable FSCTL/IOCTL code set may be limited by both the SRV or underlying file systems. (Not all are necessarily valid for each)</p><p>For buffered or direct requests, only the Input is valid on the request and only the Output is sent on the response. For any request, neither input nor output are sent in both directions.<b><i></i></b></p><p><b><i>directory</i></b><b><i></i></b><b><i>Queries</i></b><b><i>(QUERY DIRECTORY)</i></b></p><p>Allows clients to query directory enumerations on open directory handles across the network.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0029.tif" /></p><p><img file="KR101036751B1_D0030.tif" /></p><p><img file="KR101036751B1_D0031.tif" /></p><p>The QueryDirectory call matches the existing NT semantics very closely. The caller provides an InfoClass, a FileId for opening a directory, a portion of the filename (specifying wildcard/file search params or a resume name for an existing search) and any valid SL_ flags associated with that call; SRV will return the buffer up to OutputBufferLength.</p><p>There is also a new flag (SMB2_REOPEN) that can be included in the QueryDirectory flag structure. These flags are more robust versions of the SL_RESTART_SCAN flag. The latter only allows resumption of scans in which the specified search has not changed. (ie, resume *.* or t* searches.) The latter notifies the server to resume scans where the specified search has changed. In order to use this flag, the caller must guarantee exclusive use of the call and no pending action (eg, change notification). The server takes appropriate steps to perform this operation, including closing and reopening the underlying directory handle on the server side. It is transparent to the client.<b><i></i></b></p><p><b><i>CHANGE NOTIFY</i></b></p><p>This potentially long-running operation allows the client to register for change notifications on the directory.<b><i></i></b></p><p><b>format</b></p><p><img file="KR101036751B1_D0032.tif" /></p><p>The caller sends the FileID for the directory along with a CompletionFilter specifying which changes the caller is interested in. They also send the SL_WATCH_TREE flag to indicate cyclic notification behavior. Since these actions can be queued for an indefinite amount of time, they will almost always call the "async" behavior. It should also be noted that any further change notification requests on the same handle will be deferred waiting for the first change to complete, as with the local file system operating state.</p><p><b><i>information </i></b><b><i>Queries</i></b><b><i>(QUERY INFO)</i></b></p><p>Allows clients to query information from remote systems. Currently it can be used to query file information, file-system information, security information or allocation information.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0033.tif" /></p><p><img file="KR101036751B1_D0034.tif" /></p><p>The client specifies SMB2_0_INFO_* options in InfoType to indicate whether it is a request for file information, file system information, security information, or allocation information. FileId indicates the file in question (for file info or security info). For file system info or allocation requests, the volume on which the file resides is used.</p><p>A lower level of information is populated into the FileInfoClass, which depends on the type of information being queried. For file information query, this will be FILE_INFORMATION_CLASS, and for file system information it will be FS_INFORMATION_CLASS. It will be zero for allocation and security.</p><p>Currently the input buffer is only used for quota requests, as those requests take an SMB2_QUERY_QUOTA_INFO structure for the input to determine what is being requested. It will be empty for other requests.</p><p>OutputBufferLength specifies the maximum amount of data to return to the user. </p><p><b><i>Setting information (SET INFO)</i></b></p><p>Allows the client to set information on a remote system. Currently, it can be used to set file information, file-system information, security information or allocation information.<i></i></p><p><b>format</b></p><p><img file="KR101036751B1_D0035.tif" /></p><p>The type of information to be set and the specific class are set in the Flags and FileInfoClass fields as described for QUERY_INFO. Information that the input buffer to be provided is set, and FileId identifies the file.</p><p>In a SetSecurity call, the SecurityInformation field indicates information to be set (ie, OWNER_SECURITY_INFORMATION, etc.). </p><p><b><i>conclusion</i></b></p><p>The invention is susceptible to various modifications and alternative constructions, and certain exemplary embodiments of the invention have been shown in the drawings and have been described in detail above. However, the present invention is not limited to the specific form disclosed, and on the contrary, all modifications, alternative structures and equivalents are intended to fall within the spirit and scope of the present invention.</p>