Regulation of data communication by sequence number

The present invention relates to controlling the use of server resources by a client by using a sequence number incorporated in a data communication protocol for communication between the client and the server.

Many data communication protocols, such as the SMB (Server Message Block) protocol, that are still in use today are computing, for example, because network bandwidth is generally limited and memory is invaluable. It was developed in an era when resources were very different.

<p> The use of such protocols in modern networks can limit overall performance. For example, because it was designed in an era of limited memory, it uses small buffer sizes and requires more round trips to communicate large amounts of data.</p><p> In addition, existing SMB protocols have other limitations that have become apparent over time. For example, existing SMB protocols are vulnerable to denial of service attacks, and the design of this protocol makes it difficult to counter these attacks. Similarly, the method of ensuring packet security is complicated. Also, there is currently no mechanism for achieving service-like quality of operation, for example, a trusted client gets the same server resources as an untrusted client. So while existing versions of SMB are still frequently used and useful protocols, they are not ideal for use with modern network resources.</p>

<p> Various aspects of the invention relate to controlling the use of server resources by a client by using sequence numbers, such as those incorporated into a data communication protocol, for client-server communication. Various aspects introduce the use of sequence numbers into protocols where ordering is not important, providing quality of service, countering denial of service, partitioning server resources, signing secure messages, and many other benefits. To do.</p><p> The server gives the client a credit, which uses the credit to send each command to the server. Each credit corresponds to a sequence number, and the combination of sequence numbers forms a valid command window. For each command received, the server enforces that the command contains one sequence number in the valid command window and that sequence number is not used by another command. The server maintains the maximum window size, which prevents even a credited client from sending commands with a sequence number greater than the maximum sequence number corresponding to the maximum window size.</p><p> Generally, when a server receives a command from a client, it verifies that the sequence number is in the window and has not been used before. The server then removes the corresponding sequence number from the sequence numbers available to the client, thereby consuming one credit. The server then decides whether to give the client one or more other credits.</p><p> Therefore, it provides a mechanism to limit the use of server resources by controlling the number of credits given to the client through a valid operation window that contains a unique number representing each credit given to the client. The enforcement mechanism contains one sequence number in the Enabled Operations window, and its unique number is not used for another command, in order to allow further server operations for the received command. Guarantee that. The allocation mechanism controls the credits given to the client and the unique number in the valid operations window.</p><p> Other advantages will become apparent if the following detailed description is understood in conjunction with the drawings.</p><p> The present invention is shown in the accompanying figures as an example, but not a limitation, with similar reference numbers referring to similar elements.</p>

(Example Operating Environment) FIG. 1 shows an example of an appropriate computing system environment 100 in which the present invention can be implemented. This computing system environment 100 is merely an example of a suitable computing environment and is not intended to present any limitation on the scope of use or functionality of the present invention. Nor should it be construed that the computing environment 100 has any dependency or need for any one or combination of components shown within this exemplary operating environment 100.

The present invention can be used with many other general purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the present invention are personal computers, server computers, handheld devices or laptop devices, tablet devices, multiprocessor systems, and more. Includes microprocessor-based systems, set-top boxes, programmable home appliances, networked PCs, mini-computers, mainframe computers, distributed computing environments including any of the above systems or devices, etc. Not limited.

The present invention can be described in the general context of computer-executable instructions such as program modules executed by a computer. Program modules generally include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present invention can also be implemented in a distributed computing environment where tasks are performed by remote processing devices linked over a communication network. In a distributed computing environment, program modules can be located on local computer storage media, including memory storage devices, and / or remote computer storage media.

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. The components of the computer 110 can include, but are not limited to, a processor 120, a system memory 130, and a system bus 121 that connects various system components, including system memory, to the processor 120. The system bus 121 can be any of a plurality of types of bus structures, including a memory bus or memory controller, a peripheral bus, and a local bus that uses any of the various bus architectures. For example, such architectures are PCI (Industry Standard Architecture) bus, MCA (Micro Channel Architecture) bus, EISA (Enhanced ISA) bus, VESA (Video Electronics Standards Association) local bus, and PCI, also known as mezzanine bus. (Peripheral Component Including, but not limited to, the Interconnect) bus.

Computer 110 typically includes a variety of computer-readable media. The computer-readable medium can be any medium available that can be accessed by the computer 110 and includes both volatile and non-volatile media, as well as removable and fixed media. For example, computer-readable media can include, but are not limited to, computer storage media and communication media. Computer storage media are volatile and non-volatile media implemented in any method or technique for storing information such as computer-readable instructions, data structures, program modules, and other data, as well as removable and fixed media. Includes medium. Computer storage media are RAM, ROM, EEPROM, flash memory, or other memory technology, CD-ROM, digital versatile disc (DVD), or other optical disc storage, magnetic cassette, magnetic tape, magnetic disk storage, or others. Magnetic storage devices, or any other medium that can be used to store desired information and is accessible by computer 110, including, but not limited to. The communication medium usually embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transmission mechanism, and includes any information transmission medium. The term "modulated data signal" means a signal having one or more of its characteristics set or modified in such a way that information is encoded within the signal. For example, the communication medium includes, but is not limited to, a wired medium such as a wired network or a direct wired connection, and a wireless medium such as a sound wave medium, an RF medium, an infrared medium, and other wireless media. Moreover, any combination of the above is included in the range of a computer-readable medium.

System memory 130 includes computer storage media in the form of volatile and / or non-volatile memory such as read-only memory (ROM) 131 and random access memory (RAM) 132. The basic input / output system 133 (BIOS) includes a basic routine that assists in transmitting information between elements in the computer 110 during booting and the like, and is usually stored in the ROM 131. The RAM 132 typically includes a data module and / or a program module that is readily accessible to the processor 120 and / or is currently being operated by the processor 120. FIG. 1 shows, but is not limited to, an operating system 134, an application program 135, other program modules 136, and program data 137 as examples.

The computer 110 may also include other removable / fixed, volatile / non-volatile computer storage media. FIG. 1 shows reading and writing between a hard disk drive 141 that reads and writes to and from a fixed non-volatile magnetic medium and a removable non-volatile magnetic disk 152 for purposes of illustration only. An optical disk drive 155 that reads or writes between a magnetic disk drive 151 and a removable non-volatile optical disk 156 such as a CD-ROM or other optical medium is shown. Other removable / fixed, volatile / non-volatile computer storage media that can be used in typical operating environments include magnetic tape cassettes, flash memory cards, digital versatile disks, digital videotapes, solid-state RAM, and solid-state. There are ROMs, etc., but they are not limited to these. The hard disk drive 141 is usually connected to the system bus 121 via a fixed memory interface such as interface 140, and the magnetic disk drive 151 and optical disk drive 155 are usually connected to the system bus via a removable memory interface such as interface 150. It is connected to 121.

The drives described above and their associated computer storage media, shown in FIG. 1, provide computer readable instructions, data structures, program modules, and other data storage for the computer 110. For example, in FIG. 1, hard disk drive 141 is shown as storing operating system 144, application program 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, the application program 135, the other program modules 136, and the program data 137. Here, different numbers are assigned to indicate that the operating system 144, the application program 145, the other program modules 146, and the program data 147 are at least different copies. The user can enter commands and information into the computer 110 via an input device such as a tablet or electronic digitizer 164, microphone 163, keyboard 162, and a pointing device 161 usually called a mouse, trackball, or touchpad. .. Other input devices not shown in FIG. 1 can include joysticks, gamepads, satellite broadcast receiving antennas, scanners, and the like. These and other input devices are often connected to the processor 120 via a user input interface 160 coupled to the system bus, but others such as a parallel port, game port, or universal serial bus (USB). It can also be connected by the interface structure and bus structure of. The monitor 191 and other types of display devices are also connected to the system bus 121 via an interface such as the video interface 190. The monitor 191 can also be integrated with a touch screen panel, etc. it can. Note that the monitor and / or touch screen panel can be physically coupled to the enclosure in which the computing device 110 is built, as in a tablet-type personal computer. Further, a computer such as a computing device 110 can also include other peripheral output devices such as a speaker 195 and a printer 196, which can be connected via a peripheral output interface 194 and the like.

The computer 110 can operate in a networked environment using a logical connection to one or more remote computers, such as the remote computer 180. The remote computer 180 can be a personal computer, server, router, network PC, peer device, or other common network node, and although only memory storage device 181 is shown in Figure 1, it is usually a computer. Includes many or all of the above-mentioned elements related to 110. The logical connections shown in FIG. 1 include local area networks (LAN) 171 and wide area networks (WAN) 173, but can also include other networks. Such networking environments are common in offices, enterprise-scale computer networks, intranets, and the Internet.

When used in a LAN networking environment, the computer 110 is connected to the LAN 171 via a network interface or adapter 170. When used in a WAN networking environment, the computer 110 typically includes a modem 172, or other means for establishing communication over WAN 173, such as the Internet. Modem 172 can be internal or external and can be connected to system bus 121 via user input interface 160 or other suitable mechanism. In a networked environment, the program modules shown associated with computer 110, or parts thereof, can be stored in remote memory storage devices. FIG. 1 shows, as an example, the remote application program 185 resident on the memory device 181 but is not limited to this form. It will be appreciated that this network connection is exemplary and other means of establishing communication links between computers can also be used.

(Coordination of Data Communication by Sequence Number) Various aspects of the technology described herein cover mechanisms that can be adopted within a data communication protocol, such as a modified version of the SMB protocol (2.x or later). It is supposed to be. In one example of an implementation commonly described herein, this mechanism controls the flow of data / commands within this revised SMB protocol used for Windows®-based file sharing. To do. However, as it is easy to understand, the present invention is not limited to Windows®-based systems and SMB protocols, but rather examples of this technology include protocols that do not necessarily handle file data. It can be applied to all file sharing protocols and data communication protocols. For example, printers, named data pipes, generic devices Many methods for implementing the present invention can be realized, such as using the device in a communication state with a device) or the like. As such, the invention is not limited to any of the particular file-based or other examples used herein, but rather provides benefits and benefits in computing in general. Can be used in the following ways.

Referring to FIG. 2, a block diagram showing an example of a networking environment in which the client 202 communicates with the server 204 via one or more communication channels is shown. The functions and components of the client 202 and the server 204 will be described as being located on two separate computers such as the main computer system 110 and the remote computer system 180 of FIG. However, the components of these two computers, and the functions they perform, can be provided on one machine or distributed across multiple computers. For example, a computer system can include one of a variety of network equipment devices such as print servers, printers, and NAS storage devices.

The Network File System command from application program 206 is the client redirector. Processed by component) 208, client redirector component 208 communicates with the other party's common network module (SRVNET) 210 to execute commands on file system 212. Generally, the client 202 establishes a connection, then negotiates with the server 204, and finally initiates a session. As part of this, the client and server negotiate a communication protocol before the command directed by the file system is processed. In this example, the protocol agreed for this connection / session is SMB2.0, where the client-side SMB engine 220 employs the SMB2.0 driver for communication with the server 204. The Common Network Module (SRVNET) 210 also employs the SMB 2.0 provider 226, which handles client communications over this connection. Provider 226 includes, or is associated with, a coercion mechanism and data structure that ensures that the client uses the appropriate sequence number, as described below.

Focusing on the concept of coordinating data communication by sequence number, sequence number provides a mechanism by which the server throttles the amount of work that a given client issues to the server. This is achieved by having the server provide a window of available sequence numbers that the client can use to identify a given command. Adopting the concept of credits to perform sequence numbers and desired actions, one credit is on the server side, such as the memory needed to back up one operation and the CPU cycles that the operation can consume. Gives the client the right to consume some of the resources. The client consumes one credit for each command it sends and is given zero, one or more additional credits, depending on the response of the server. The client cannot reuse the sequence number, so the number of commands that the client can issue is controlled. For convenience, we use monotonically increasing sequence numbers, but the unique numbers (per session / connection) are equivalent.

For example, if a server gives a client five credits, the server gives the client the right to submit up to five operations at the same time. When the server needs to suppress a client, it suppresses it by reducing the credits available to that client. The server does this by giving credit if it wants to give the client more resources to work with.

This gives the server multiple options. By giving a client zero credit, the server reduces the resources allocated to that client. Alternatively, by returning one credit, the server maintains its previous window size. By returning multiple credits, the server allocates more resources to the client to execute the command. One constraint is that the server has zero window size (unless the server has a way to credit out of band, assuming that the protocol is strictly a command response protocol. It means that it cannot be (without a valid sequence number). This constraint does not apply if there is a way to credit the client without requiring the client to request credit within a protocol using this method.

The negotiation request / response has a sequence number of zero (also called a message ID or MID) and a window size of one. In SMB2.0, the following header makes it easy to pass this information.

<tables num="1"><img file="JP2006333434A_D0001.tif" /></tables>

As can be seen from the header structure above, the client requests as many credits as it wants, but the server manages to give credits to the client. The server can therefore shrink or expand the window based on the client's ID, behavior, or any other attribute or criterion. The sequence number also provides a way to uniquely identify the command sent from the client to the server for each given connection.

Clients and servers are started by establishing a command window. The command window displays the default or negotiated initial sequence number (ISN) (also known as the initial message ID or MID) and the number of credits (NoC) that represents the range of acceptable numbers that the server accepts to identify a given command. ) And start by using. Therefore, the command window initially contains [ISN, ISN + NoC-l]. For most protocols, the defaults can be ISN = 1, NoC = 1, so if the command window is simply [1,1] when first negotiated, the server will only accept to identify the command. Indicates that the sequence number of is 1.

As communication progresses, the client moves through the numbers in the window by using up the numbers in the range. Once a number is used, it cannot be used again. This is because it is so enforced by the server. At the same time, the server can extend the end of the window as it decides by giving the client more credits. For example, if the command window is [A, B], when the client sends command A, the valid command window is basically [A + 1, B]. The server can give the client any credit, from zero to a realistic number, when responding to command A. Therefore, if the server returns N credits, the valid command window will be [A + 1, B + N].

When using sequence numbers within an acceptable range, they do not have to be out of order. The protocol is set up to facilitate the asynchronous use of sequence numbers as long as the sequence numbers used are within the valid range. This allows network protocols to send packets when they are available, rather than trying to force them to be sent in order. Therefore sequence number A is needed for very large packets, while A + 2 comes in while the buffer is being prepared for the transmission of A + 1, and that A + 2 is very much. If it is small, it is justified to send A + 1 and A + 2 without waiting for the transmission of A to start (as long as the end of the window A + 2).

If there is a valid command window called [1,5] and packets 2, 3 and 4 are sent, the server will conversely credit and window [1,8] excluding {2, 3, 4} ( 1 to 8 means all numbers except 2 to 4). Eventually, the server is likely to stop giving credit until packet 1 is sent and the window can slide. At this point, if the client sends a 1 and the server responds and credits, the window becomes [5,9].

Enforcement of the valid command window is done on the server side. With this system, the client-side structure has a sequence number and a maximum sequence number at that time, and uses interlocked compares and increments as the only required synchronization method. It can be simple.

Therefore, a valid command window (also known as a valid operation or Valid Op window) contains a window with a valid ID that the server accepts. The client does not need to maintain a view of the valid window by sending each subsequent command with the next valid sequence number (up to its valid credits). The client needs to understand the concept of "maximum window size" (discussed below). An example of using the valid command / operation window is described below.

All operations that may block for an infinite amount of time, such as change notifications and reading or creating named-pipes (because they may be pending on the oplock break), are blocked. Considered an operation. To facilitate such operations, the client can provide an "operation context" value, i.e., a blocking flag, in the send command. The server then responds when it successfully initiates an operation, allowing the sequence number to be incremented even if the operation is still being processed on the server side. However, the resources held by such long-running operations are often a subset of the resources required for normal commands. Therefore, the server is a "Blocking Op" that can be consumed by the client. The maximum number of "credits" (also known as long operation credits or LOC) can be determined. Sequence numbers also allow long-term continuation commands to be balanced with commands with multiple responses from the server by controlling how many resources the client can consume.

Therefore, one extension to the valid command window is to allow the window to continue to slide normally and not be stagnant by operations that can take an infinite amount of time. For this purpose, the client is given a certain number of Blocking Op credits by the server, and all operations issued with the Blocking Op flag are one Blocking. Consume Op credits. When the server receives a command, it can send an intermediate response back to the client with a flag set indicating that it has received a long-term continuation command, returning a long-term continuation command ID, also known as an asynchronous ID (AsyncID). This response allows the valid command window to slide normally. When the long-running command completes, a new response is sent back to the client with a long-running command ID to indicate which packet it is responding to. This send-response-response architecture allows the window to keep moving, and the credit mechanism allows the server to retain control over how many resources the client can consume. The server can even shrink the valid command window if a number of long-running operations are in progress from the client.

The alternative implementation includes a protocol that allows the client to suggest to the server that long-lasting commands may come. Another implementation of the asynchronous concept can also cause the client to issue an interim "accept" etc., which allows asynchronous / blocking operations to "send" as opposed to just send-response-response. -Answer-Send-Answer". Some of the underlying transports (eg TCP) are often tuned for request-response traffic, which can cause delays in request-response-response situations.

Due to the asynchronous nature of the protocol and transport, the current valid window cannot be directly equal to the current minimum sequence ID plus credits. This is because some intermediate commands may be received first, that is, it may take a long time to process, for example, a command with sequence ID = 1. However, the server can impose restrictions on how far this enabled window can be extended before it stops expanding. Continuing with the previous example, the server can specify a maximum window size of 10. That is, if the server receives and processes packets 2, 3, 4, 5, and 6 before receiving or processing packet 1, the valid operations (command) window is [1,10]. Extend to. Therefore, the valid sequence numbers are 1, 7, 8, 9, and 10. However, the next time the server receives and processes packet 7, the valid operations (command) window does not slide to [1,11], with acceptable sequence numbers 1, 8, 9, and 10 [ It stays at 1,10]. The response for command B indicates a credit of -1 and tells the client that the client has reached the end of its acceptable limit, that is, the value of that credit is currently 4. This is one way the server prevents the client from skipping a given number in the sequence, which prevents the window from sliding well. It also indicates a value that issues a "Blocking Op" to the server for commands that take a long time.

Tracking a valid command window on the server side can be computationally expensive as the server must track the intersecting sets. In order to simplify this, in one example of the implementation, the above-mentioned maximum window size is established as the maximum size allowed by the server for the command window. Once this is established, the server allocates a buffer representing this size, and when a command comes in, the value at that location in the buffer changes. As long as the window size is less than or equal to the maximum window size, when the window start point moves forward, the server moves its buffer pointer forward. Similarly, as the endpoint expands as credits are awarded, the server moves its endpoint pointer along the buffer. The calculation handles the situation where the buffer "wraps" the maximum window size. You can dynamically increase the maximum window size by allocating a larger buffer and copying the current value into it. Use an interlocked operation that starts as AVAILABLE to track the status of valid commands in a window. Upon receiving a command from the client, those interlocked operations transition to IN_PROGRESS, and when a response (or interim response in the case of long-running commands) is sent, it transitions to USED. If the value to transition to USED is the first value in the window, the window slides forward until it encounters a non-USED value.

In another alternative implementation, the server can revoke credits via an alternative channel or unsequenced communication. For example, if a server gives a client 10 credits and wants to cut that client's credits to 5, this condition usually does not occur unless the client uses 5 commands. If the client is dormant, the server will tell you that in the next N seconds the client will have to spend 5 credits, otherwise it will be a breach and will be terminated (or lose credits). Show to the client. This allows the server to suppress the client without relying on the client to move its own window.

The operation of the present invention using various examples will be described, and the state at that time will be described in the following format.

<tables num="2"><img file="JP2006333434A_D0002.tif" /></tables>

The Min column shows the lowest unused client sequence number available to the client, and the Current Credits show how many credits are being given to the client in the form of (regular credits, Blocking Op credits). The client consumes one credit on transmission and, in some cases (depending on the response), increments again on reception. The next column, which simply says "Credits," shows the maximum number of credits allowed to the client at that time.

Valid and Max show server-side structures for authenticating sequence IDs (clients don't need to know anything about them). Valid indicates a Valid Op Window and an exception to the sequence ID that has already been used (for example, tracked by a bitmap), and Max is a MaxCommandWindow that the client can insert before completing the first operation. It shows an operation that will result in a window shift.

Figures 3-9 show the Valid Op window 330._sRepresents an example of how to extend when held on server 204 (in Figures 3-9, for example, Figure 3 shows 330._sHas a valid operation window labeled, Figure 4 shows 430._sWhen the valid operation window changes, such as having a valid operation window with the label, the first number on that label changes).

In FIG. 3, the client is given 5 credits and 1 as the first sequence number (ie MID). The allocation component 322 generally uses some of the criteria 320 described above, such as the client type, to determine the amount to give to the client. Therefore, in this example, the valid operation window at that time is [1,5], and in Figure 3, window 330._sIt is represented vertically by the individual numbers in. Therefore, server 204 accepts packets with sequence numbers 1, 2, 3, 4, or 5 from this client 202. Alternatively, this is also expressed in the following format described above.

<tables num="3"><img file="JP2006333434A_D0003.tif" /></tables>

Valid Op window 320 to trivially reject packets_sTo use. Those packets are Valid Op window 320_sIf present in, server 204 checks the internal exception map to ensure that the sequence number is no longer in use.

For normal monotonously increasing reception, the client sends a packet with MID = 1, and the client and server transition to the states shown in Figure 4 and the table below ([1,5] is valid). However, 1 is truly valid only for the response from the server, not for another reception from the client, and will fail if Min = 2 is checked first. Become).

<tables num="4"><img file="JP2006333434A_D0004.tif" /></tables>

In FIG. 4, the server receives and processes the command with sequence number = 1. That is, 1 is no longer a valid sequence number for subsequent commands, which is indicated by the bracketed {1} in the Valid / except column in the table above, and 430 in Figure 4._sIt is shown in the valid operation window labeled as.

As shown in Figure 5 and the table below, when responding, the server gives the client an additional +1 credit on the response and slides the window.

<tables num="5"><img file="JP2006333434A_D0005.tif" /></tables>

Then, the valid window that the client has is [2,6]. Suppose there is an asynchronous transmission on the transport, which causes an out-of-order reception, such as when the server receives command 3 before (and before responding to) command 2. The Valid Op window 630 then, as shown in Figure 6 and below._sHowever, it will exist conceptually.

<tables num="6"><img file="JP2006333434A_D0006.tif" /></tables>

In this table, the valid window expands, but the maximum window does not slide. But when the server receives and responds to command 2, window 730_sSlides as in both Figure 7 and:

<tables num="7"><img file="JP2006333434A_D0007.tif" /></tables>

Second, suppose a malicious client wants to run out of resources on the server by sending commands and denying responses. Here, the client sends commands 4 and 5 to the server and refuses to respond. The states are as shown in FIG. 8 and below.

<tables num="8"><img file="JP2006333434A_D0008.tif" /></tables>

When a command with sequence IDs 6, 7, and 8 is sent, the client loses credit and all packets are rejected due to credit enforcement, as shown in Figure 9 and the table below. To.

<tables num="9"><img file="JP2006333434A_D0009.tif" /></tables>

Moving on to the example of forcing the maximum window, use Figures 10-13 and similar tables. Suppose a malicious client attempts to send packets after N + 1 without sending packet N. The examples in Figures 10-13 start in the state before the last attacker. That is, FIG. 10 is essentially FIG. 7.

<tables num="10"><img file="JP2006333434A_D0010.tif" /></tables>

The client sends commands 5, 6, 7, 8, 9, 10 and the server responds, but command 4 is not sent. This state is shown in Figure 11 and the table below.

<tables num="11"><img file="JP2006333434A_D0011.tif" /></tables>

Note that the client still has 5 credits, as there are still 5 executable slots in the command window. However, if the client sends command 11 and the server responds, the conditions shown in Figure 12 and the table below occur.

<tables num="12"><img file="JP2006333434A_D0012.tif" /></tables>

The client then continues on 12, 13 and 14. Since there are no slots available in MaxWindow, the number of credits available to the client is reduced by one for each command. This continues for commands 12, 13 and 14.

<tables num="13"><img file="JP2006333434A_D0013.tif" /></tables>

As shown in Figure 13, the only command that the server accepts from the client is command 4.

As is easy to understand, the attributes of the sequence number window are very advantageous in multiple desirable scenarios. Some of these scenarios are to prevent denial of service, enable quality of service, and provide a common language for clients and servers to reference commands executed over a given connection. Allows long-lasting commands and commands with multiple responses from the server, while balancing by controlling how many resources the client can consume, and continuous security signing. Includes making it available for use.

With respect to preventing denial of service, the server can limit the amount of resources that a client connection can consume until it authenticates a given client and that client works properly. For example, by allowing the server to control the resources allocated to the client, the server can enter "panic mode" if a suspected attack is detected, minimizing the resources available to that client. Shave and reinstate those resources on a trustworthy basis. The server gives each client a window small enough for work to occur, while preventing any single client from occupying essentially all of the resources. Once the attack is complete or mitigated, the server can begin re-resources the proven client.

With respect to enabling quality of service, a variable window scheme allows the server to increase or decrease the amount of resources allocated to the client based on the client's ID and / or behavior. For example, a server can allocate more resources to a web server connecting to a file server than to a single user accessing an individual document. As another example, if another server is a database server accessing a file server, that file server weights the number of credits given higher than the number of credits given to the average user. Can be done.

In addition, when controlling the quality of service, the allocation of resources to the client can be dynamically changed based on the different needs of the client. This allows the server to credit or take into account other information in a completely fair manner. The administrator can configure the machine based on resource priority, which can be dynamically used and modified as the user makes a connection and disconnects.

Sequence numbers also provide a common language for clients and servers to reference commands executed over a given connection. This is useful when building a variety of features, including persistent processing. For example, if a connection is lost because both the client and the server have agreed on a common language for identifying commands as they are sent and received, namely the sequence numbering mechanism, which command There is an easy way for the server and client to determine when the connection is restored, which command was received and which command was not received. Without such a set scheme, it would be even more difficult to track, especially if the command ID could have been selected and reused by the client.

The sequence number also allows the security signature to be used continuously without the extreme performance issues of the current model, and the transmissions do not have to be out of order (although the checksum of all packets is still calculated). Will need to be, and the entire packet will need to be received before it is issued). There can be no reproducibility when it comes to packet signatures. More specifically, the signing network protocol requires the index number to be included in the packet to prevent the reproducibility of the signed packet, otherwise the attacker simply reissues the packet and the packet. You no longer have to give up and the packet remains valid. Other methods include time stamps and the like, but they require some form of synchronization between the client and server. When using index numbers, the client must ensure that the server receives packet 1 before sending packet 2, so network traffic between the client and server is often in sequence. It will be lined up.

The sequence number built in as the command ID and the valid window supported on the server inevitably cause parallel command transmission with the sequence number inside. Each command can only be issued once because the server enforces a valid window, which ensures that the key used for signing is unique for each authenticated connection. As long as playability is not an issue. If the command ID is repeated, reproducibility can be an issue, so to prevent this, a sequence number of about 32-bit or 64-bit is desirable and if the disconnected connection can be recovered. , Perhaps 64-bit is more desirable.

The present invention can accept a variety of modifications and alternative configurations, but specific exemplary embodiments have been illustrated and described in detail. However, it should be understood that it is not intended to limit the invention to the particular embodiments disclosed, but rather to include all modifications, alternative configurations, and equivalents that fall within the spirit and scope of the invention. Is.

<figref num="1">It is a figure which shows one specific example of the general-purpose computing environment which can incorporate various aspects of this invention.</figref><figref num="2">It is a block diagram which shows an example of the network environment in which a client communicates with a server according to various aspects of this invention.</figref><figref num="3">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="4">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="5">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="6">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="7">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="8">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="9">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="10">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="11">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="12">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref><figref num="13">It is a figure which shows the data of the client and the server held for using a sequence number by various aspects of this invention.</figref>