Patent Application
20160080488
Data replication systems use network protocols to communicate replication information. Generally, an application-specific Internet Protocol (IP) or Fibre Channel (FC) protocol is used to communicate replication information. It is with respect to this general technical environment that the present application is directed.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Examples of the present disclosure describe implementations of a file-based protocol for request processing. A request, sent from a first device, may be received at a second device using a file-based transport protocol as a transport service. The request may be processed by the second device using a virtual file system, which implements a transport layer to interface with the file-based transport protocol. The transport layer of the virtual file system may be utilized to receive, evaluate and process transmissions from the file-based transport protocol. The virtual file system may forward a response to the file-based transport protocol for transmission to the first device. The virtual file system may be further usable to provide added capability such as managing access control and connection loss detection with the file-based transport protocol, among other examples.
Additional aspects, features, and/or advantages of examples will be set forth in part in the description which follows and, in part, will be apparent from the description, or may be learned by practice of the disclosure.
Non-limiting and non-exhaustive examples are described with reference to the following figures.
Examples of the present disclosure provide implementations of a file-based protocol for request processing. Implementation of a file-based protocol provides added capability compared with an application-specific protocol. For example, a file-based protocol may enable capabilities such as enterprise security management, multi-channel connection processing, remote direct memory access (RDMA), encryption, signing, and continuous availability, among others. A virtual file system may be implemented to interface with the file-based protocol at a transport layer in order to utilize the file-based protocol for request processing. This can improve processing of requests when using a file-based protocol. Further, examples of the present disclosure provide added capabilities, whereby capabilities such as access control and connection loss detection can be implemented.
Examples of the present disclosure describe implementations of a file-based protocol for request processing. A request, sent from a first device, may be received at a second device using a file-based transport protocol as a transport service. The request may be processed by the second device using a virtual file system, which implements a transport layer to interface with the file-based transport protocol. The transport layer of the virtual file system may be utilized to receive, evaluate and process transmissions from the file-based transport protocol. The virtual file system may forward a response to the file-based transport protocol for transmission to the first device.
As an example, a request can be for data replication such as a request for processing a remote data write. However, the present disclosure can relate to any request for any information transmittable between two devices. Examples of devices in which data replication requests may be performed include a source machine and a target machine. In alternative examples, a request may be sent to more than one device for processing. For example, a source machine may request data replication on a number of target machines. Requests may be sent to each of the target machines and the source machine may receive responses from each target machine.
A file-based transport protocol may be used as a transport service for communicating between devices. Examples of file-based transport protocol include but are not limited to Network File System (NFS), Server Message Block (SMB), Apple Filing Protocol (AFP), and Network Control Program (NCP). Furthermore, the present disclosure is not limited to using a single file-based transport protocol and may utilize multiple file-based protocols to implement a transport service between devices. Moreover, it should be understood that the present disclosure is implementable with different iterations of a file-based protocol. When using SMB as an example, the present disclosure may be implementable with any iteration of Server Message Block (SMB) protocol, including SMB 2.0 or SMB 3.0, among other protocols.
When considering transport of information for request processing, a transport layer is provided to support processing of a request. In an example where a request is for data replication, a file-based transport protocol may lack capability for directing and processing information for a data replication request. Additional steps may need to be taken to receive, evaluate and process a request for data replication.
A file-based protocol connection share 112 may be implemented on a source machine 102 and a file-based protocol connection share 114 may be implemented on the target machine 104. Using respective connection shares 112 and 114, a communication channel may be established between the source machine 102 and the target machine 104. In one example, file-based protocol connection shares may be direct. However, in alternative examples, connection shares for multiple devices may be connected using the file-based transport protocol. Request and response data may be transmitted between devices using a communication channel of the file-based transport protocol.
Continuing with the example where the replication request is received at the file-based protocol connection share 112, the request is transmitted to the file-based protocol connection share 114 of the target machine 104. The request is then forwarded to a virtual file system 116 of the target machine 104 for processing. Data transported via the file-based transport protocol may need to be modified for replication to occur on the target machine 104. The virtual file system 116 may evaluate and process transmission data received from the file-based transport protocol to perform data replication on the storage 118 of the target machine 104.
After the data replication request is sent to the storage 118, the virtual file system 116 will process a response to the request. The processed response is forwarded to the file-based protocol connection share 114 on the target machine 104. From there, the file-based transport protocol transmits the response to the file-based protocol connection share 112 on the source machine 102. The file-based protocol connection share 112 on the source machine 102 forwards the response to the virtual file system 108 of the source machine 102 for processing. The virtual file system 108 transmits an I/O response to the application 106 with respect to the original I/O request.
The storage replica transport 202 is implemented at a transport layer to interface with the file-based transport protocol at a target machine 104. The storage replica transport 202 may be usable to send, receive, evaluate and process transmissions of the file-based transport protocol. As an example, the storage replica transport 202 may receive data transmissions from the file-based transport protocol and process the transmissions into a single message to provide to a replication manager 204. The storage replica transport 202 of the target machine 104 may also be used to process and encode a response to the request, for transmission back to a source machine 102.
The replication manager 204 may include a replication engine to perform data replication on the storage 118 of the target machine 104. In one example, the request received is a data replication request for a log write. A log write may occur on a source machine 102 then be replicated on any of a plurality of target machines, such as target machine 104. Once, the replication manager 204 receives the request message from the storage replica transport 202, the replication request may be processed on the storage 118. The replication manager 204 then sends a response to the storage replica transport 202. In one example, the response may include indication that successful processing of a replication was performed. In other examples, the storage replica transport 202 may communicate with the replication manager 204 to determine a status of the request, for example, if it was not completed successfully.
As identified above, the storage replica transport 202 also communicates with the file-based transport protocol, for example via a connection share 114 established on the target machine 104. Once a response to the request is received from the replication manager 204, the storage replica transport 202 may encode the response as an I/O packet and forward the I/O packet to the file-based protocol connection share 114 for transmission to another device such as a source machine 102.
In further examples, a source machine 102 may also include a virtual file system 108 (as referenced in
The storage replica transport 202 may possess capability to evaluate types of requests. Examples of types of requests which the virtual file system 116 may determine as processable can include but are not limited to write requests, read requests, file system control requests, connection establishment requests, directory control, query information, disconnection and connection close events, among others. Requests can also be denied by the storage replica transport 202. In that instance, the storage replica transport 202 can communicate with the file-based transport protocol to notify an application that a request cannot be completed.
In an example where SMB is used as the file-based transport protocol, the virtual file system 116 backs the file-based protocol connection share 114 on a target machine. The file-based protocol connection share 114 can be configured to accept incoming requests transmitted via I/O request packets (IRP). As one example, a type of request that may be handled by the virtual file system is data copy request, such as an IRP_MJ_WRITE. The virtual file system 116 backing the file-based protocol connection share 114 invokes the storage replica transport 202 of the target machine 104 to evaluate, decode data from a buffer of the request. Examples of exemplary instructions/commands that a virtual file system can process when SMB is implemented as the file-based transport protocol include:
Handling IRP_MJ_CREATE
Handling IRP_MJ_DIRECTORY_CONTROL
Handling IRP_MJ_CLEANUP
Handling IRP_MJ_FILE_SYSTEM_CONTROL
Handling IRP_MJ_WRITE
The storage replica transport 202 may encode and decode data into request/response packets. The storage replica transport 202 may decode packet data received from the file-based transport protocol to be able to properly process a request such as a data replication request. Additionally, the storage replica transport 202 may encode control data into a response to a request before forwarding the response to a connection share of the file-based transport protocol, so that a response can be properly processed by a virtual file system existing on another device, such as a source machine 104 as referenced in
With respect to processing of request packets, the storage replica transport 202 may receive a plurality of packets from the file-based transport protocol. In order to process the plurality of packets, the storage replica transport 202 may decode a request/response by implementing re-transmission detection logic and message re-assembly logic. This enables transformation of the plurality of request packets back into a single request message that can be interpreted by the replication manager 204. For example, a file-based protocol may be allowed to chunk buffer a request into smaller pieces and retransmit a same piece of data multiple times. Without applying message re-transmission logic and message re-assembly logic, a replication engine of the virtual file system 116 may receive multiple request data belonging to a same request. In examples, because typical application-specific replication transport protocols do not allow chunking and retransmission, replication manager 204 may not be able to process data for replication. Additionally, the possibility is present that request data may be received out of order and thus unable to be processed correctly by a replication engine. The storage replica transport 202 can be used to bridge the communication gap between a file-based transport protocol and a replication engine. Refer to the description of
The source virtual file system 108 (created on a device such as the source machine 102 in
When a request is initiated, the source virtual file system 108 may send out a replication request message to the connection share 114 of the file-based transport protocol, the replication request message including control data may be encoded into a binary data buffer of an I/O request packet (IRP). The source virtual file system 108 may encode 220 control data into the binary data buffer so that a target virtual file system 116 is able process a transmission of the file-based transport protocol. As an example, control data may be encoded within an offset and a length field of the IRP. The virtual file systems may be used to enable data transmitted over the file-based transport protocol to be properly processed for data replication. As an example, connection shares 112 and 114 may act as receivers of requests or responses. A sender of a response or request may initiate a direct call to a connection share on a remote machine using the file-based transport protocol. As the file-based transport protocol is a file level protocol, the file-based transport protocol is likely designed based on an idempotent nature of a file it is transmitting. Thus, during transmission between a source machine and a target machine, the file-based transport protocol may chunk buffer of the I/O request into smaller pieces and possibly retransmit same pieces of data multiple times. Therefore, the target virtual file system 116 needs to take further action to properly process a replication request.
In an example, the source virtual file system 108 encodes 220 the control data into an IRP offset and length field. This control data is used by the target virtual file system 116 to decode transmissions of the file-based transport protocol by applying retransmission logic and message reassembly logic. In an example where SMB is used as the file-based transport protocol, a buffer sent through SMB can be described as containing a 64-bit offset and 32-bit length which identifies which range of a file needs to be replaced by this buffer. The source virtual file system 108 may be used to encode control data into a higher 32 bits of file offset so that chunking and retransmission can be detected when a message is received at a target machine. With SMB, it is possible to chunk the message and send multiple buffers to a target. To be able to reassemble those buffers into a message, more specifically to know whether all parts of that message have been received, a total size of a message needs to be known. The target virtual file system 116 evaluates the control data to reassemble transmissions of the file-based transport protocol into a single replication message.
Of the upper 32 bits of control data (e.g., in a 64 bit SMB transmission), a bit range of 32 to 47 may be used for message reassembly logic. SMB transmission alone is not acceptable to send logs as a single message, since a typical log message is at least 2 MB in size. SMB guarantees that chunking size will be an integral multiple of 64 KB. In one example, a sender buffer is divided by 64 KB and a record number of such 64 KB chunks that will be send through SMB. By doing this, a bit range of 32 to 47 can describe up to 4 GB of message size. Based on identification of a minimal chunking unit defined in an SMB protocol, which is 64 KB, 16 bits is enough to define a length of a message. That is, 16 bits of control data are utilized to determine a total message length. Encoding 16 bits of message length into the control data informs the target virtual file system 116 of what length should be expected for a particular request message. In an example, the target virtual file system 116 may employ a counter to track how much data, belonging to a same request message, has been received. Message reassembly logic may be applied based on the SMB chunking
Of the upper 32 bits of control data (e.g., in a 64 bit SMB transmission), a bit range of 48 to 63 may be evaluated to detect retransmission, where this range is further divided into slot id and sequence id for the purpose of detecting retransmission. As 16 bits of control data are utilized to for evaluating total message length, another 16 bits (of the 32 bits of control data) may be allocated for data chunk retransmission. For example, 11 bits may be allocated to identification of a slot id and another 5 bits may be allocated to identification of the sequence ID. Data retransmission logic may be applied by the target virtual file system 116 to detect chunk retransmission. Each time a message is needed to deliver, a sender and a receiver will negotiate which slot this message will be delivered to and which sequence id that is accepted by the receiver. The target virtual file system 116 can evaluate whether the sequence ID does not match that of the sender. If this occurs, that message is treated as duplicate. Even though there are 11 bits used for slot id, SMB only allow highest bit of file offset to be 0. Therefore, 10 bits may be valid for a slot number. In one example, sliding windows may be utilized to process offset control data. For example, a slot id may correspond to a sliding window ID, and a sequence ID may correspond to a current window acceptable sequence ID. This can increase efficiency in processing of data.
Referring back to
The replication manager may use a replication engine to perform a write of the data to be replicated. After the write is completed, the target virtual file system 116 may create a response message to be sent back to the source virtual file system 108 and initiate a direct call to the connection share 112 of the file-based transport protocol of the source. In that example, a target machine will be the sender and a source machine will be the receiver. Thus, the response message is encoded 230 by the virtual file system 116 and attached to an I/O request packet to be forwarded 232 to the connection share 112 of the file-based transport protocol. The target virtual file system 116 will transmit 234 the IRP to a connection share 112 of the file-based transport protocol on a source device. That IRP will be forwarded 236 to a virtual file system 108 on the source for processing. The source virtual file system 108 may decode 238 the IRP so that the response can be processed.
Continuing an example where SMB is used as the file-based transport protocol, the virtual file systems of the source and target machines may be implemented to create an SMB share, manage connection establishment and close of the SMB share, provide connection loss detection, provide access control, and manage data transmission between an SMB share created on a source machine and an SMB share created on a target machine. The following are exemplary instructions/commands for SMB share creation and deletion:
Connection Establish and Close
With respect to connection loss detection, SMB does not have callback to notify the file handle on sender side when SMB connection behind this file handle is lost. Virtual file systems on a source and target may be implemented to a detect connection failure. The source virtual file system 108 may send an I/O request packet such as an IRP_MJ_DIRECTORY_CONTROL, through this file handle. When the target virtual file system 116 receives this IRP, it may return an I/O request packet such as STATUS_PENDING and pend the IRP until disconnection happens. If SMB connection is lost, all pending IRPs are still guaranteed to be completed by SMB. The source knows that a connection is lost when it gets a completion callback for this IRP.
Furthermore, a virtual file system may manage access control with respect to connections created via the file-based transport protocol. Below are examples of exemplary instructions/commands for managing access control when SMB is implemented as the file-based transport protocol:
Access Control
Flow 300 passes from operation 302 to operation 304, where a request is processed by a virtual file system. In one example, the virtual file system processing the request may be implementing a transport layer to interface with the file-based transport protocol. This enables the virtual file system to receive and evaluate transmissions of the file-based transport protocol.
At operation 306, a response to the request may be generated and sent to a device that initiated the request. The virtual file system may be used to generate the response and forward the response to the file-based transport protocol for transmission to the first device, for example which initiated the request.
Based on the evaluation of the control data, the virtual file system may move to operation 404, where transmissions of the file-based transport protocol are decoded. In decoding of the transmissions of the file-based transport protocol, the virtual file system may apply re-transmission detection logic and message re-assembly logic based to reassemble a message for processing by a replication engine of the virtual file system. This enables the request to be processed in a form that the replication engine can understand.
Flow 400 passes from operation 404 to operation 406, where the virtual file system may process a response to the request. In operation 406, the virtual file system may encode control data for the response into an input/output (I/O) request packet for transmission to a device which initiated the request. As an example, the virtual file system may encode control data into an upper thirty-two (32) bits of an offset of the I/O request packet for a transmission via the file-based transport protocol.
Afterwards, the encoded response is forwarded to the file-based transport protocol to transmit the response to another device. In an example, the device may be a device that initiated the request. However, in alternative examples, the requests and response may be notified to other devices as well.
Continuing on, flow 410 may determine 426 whether transmissions have been completed. Transmissions may include sending and receiving of requests as well as sending and receiving of responses. If it is determined that transmissions have not been completed, connection loss detection 420 may be implemented. If it is determined that transmissions have been completed, a connection with the file-based transport protocol may be temporarily disconnected or terminated.
As stated above, a number of program modules and data files may be stored in the system memory 506. While executing on the processing unit 504, the program modules 508 (e.g., virtual file system 108, Input/Output (I/O) manager 524, and other utility 526) may perform processes including, but not limited to, one or more of the stages of the operational flow 400 illustrated in
Furthermore, examples of the invention may be practiced in an electrical circuit comprising discrete electronic elements, packaged or integrated electronic chips containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic elements or microprocessors. For example, examples of the invention may be practiced via a system-on-a-chip (SOC) where each or many of the components illustrated in
The computing device 502 may also have one or more input device(s) 512 such as a keyboard, a mouse, a pen, a sound input device, a touch input device, etc. The output device(s) 514 such as a display, speakers, a printer, etc. may also be included. The aforementioned devices are examples and others may be used. The computing device 504 may include one or more communication connections 516 allowing communications with other computing devices 518. Examples of suitable communication connections 516 include, but are not limited to, RF transmitter, receiver, and/or transceiver circuitry; universal serial bus (USB), parallel, and/or serial ports.
The term computer readable media as used herein may include computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, or program modules. The system memory 506, the removable storage device 509, and the non-removable storage device 510 are all computer storage media examples (i.e., memory storage.) Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture which can be used to store information and which can be accessed by the computing device 502. Any such computer storage media may be part of the computing device 502. Computer storage media does not include a carrier wave or other propagated or modulated data signal.
Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” may describe a signal that has one or more characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media may include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.
One or more application programs 666 may be loaded into the memory 662 and run on or in association with the operating system 664. Examples of the application programs include phone dialer programs, e-mail programs, personal information management (PIM) programs, word processing programs, spreadsheet programs, Internet browser programs, messaging programs, and so forth. The system 602 also includes a non-volatile storage area 668 within the memory 662. The non-volatile storage area 668 may be used to store persistent information that should not be lost if the system 602 is powered down. The application programs 666 may use and store information in the non-volatile storage area 668, such as e-mail or other messages used by an e-mail application, and the like. A synchronization application (not shown) also resides on the system 602 and is programmed to interact with a corresponding synchronization application resident on a host computer to keep the information stored in the non-volatile storage area 668 synchronized with corresponding information stored at the host computer. As should be appreciated, other applications may be loaded into the memory 662 and run on the mobile computing device 600, including virtual file system 108, IO manager 524, and other utility 526 described herein.
The system 602 has a power supply 670, which may be implemented as one or more batteries. The power supply 670 might further include an external power source, such as an AC adapter or a powered docking cradle that supplements or recharges the batteries.
The system 602 may include peripheral device port 678 that performs the function of facilitating connectivity between system 602 and one or more peripheral devices. Transmissions to and from the peripheral device port 672 are conducted under control of the operating system 664. In other words, communications received by the peripheral device port 678 may be disseminated to the application programs 666 via the operating system 664, and vice versa.
The system 602 may also include a radio 672 that performs the function of transmitting and receiving radio frequency communications. The radio 672 facilitates wireless connectivity between the system 602 and the “outside world,” via a communications carrier or service provider. Transmissions to and from the radio 672 are conducted under control of the operating system 664. In other words, communications received by the radio 672 may be disseminated to the application programs 666 via the operating system 664, and vice versa.
The visual indicator 620 may be used to provide visual notifications, and/or an audio interface 674 may be used for producing audible notifications via the audio transducer 625. In the illustrated example, the visual indicator 620 is a light emitting diode (LED) and the audio transducer 625 is a speaker. These devices may be directly coupled to the power supply 670 so that when activated, they remain on for a duration dictated by the notification mechanism even though the processor 660 and other components might shut down for conserving battery power. The LED may be programmed to remain on indefinitely until the user takes action to indicate the powered-on status of the device. The audio interface 674 is used to provide audible signals to and receive audible signals from the user. For example, in addition to being coupled to the audio transducer 625, the audio interface 674 may also be coupled to a microphone to receive audible input, such as to facilitate a telephone conversation. In accordance with examples of the present invention, the microphone may also serve as an audio sensor to facilitate control of notifications, as will be described below. The system 602 may further include a video interface 676 that enables an operation of an on-board camera 630 to record still images, video stream, and the like.
A mobile computing device 600 implementing the system 602 may have additional features or functionality. For example, the mobile computing device 600 may also include additional data storage devices (removable and/or non-removable) such as, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
Data/information generated or captured by the mobile computing device 600 and stored via the system 602 may be stored locally on the mobile computing device 600, as described above, or the data may be stored on any number of storage media that may be accessed by the device via the radio 672 or via a wired connection between the mobile computing device 600 and a separate computing device associated with the mobile computing device 600, for example, a server computer in a distributed computing network, such as the Internet. As should be appreciated such data/information may be accessed via the mobile computing device 600 via the radio 672 or via a distributed computing network. Similarly, such data/information may be readily transferred between computing devices for storage and use according to well-known data/information transfer and storage means, including electronic mail and collaborative data/information sharing systems.
According to one example, a request that is sent from a first device may be received at a second device using a file-based transport protocol as a transport service. In an example, the request may be a data replication request for a remote write of a log file written into a data storage of the first device. The request may be processed by the second device using a virtual file system, which implements a transport layer to interface with the file-based transport protocol. The transport layer of the virtual file system may be utilized to receive, evaluate and process transmissions from the file-based transport protocol. Evaluation of transmissions may include evaluating control data of each transmission from the file-based transport protocol. As an example, the transport layer may evaluate an upper thirty-two (32) bits of an offset for a transmission sent by the file-based transport protocol to detect chunk transferring and data re-transmission. The transport layer of the virtual file system may receive a plurality of transmissions from the file-based transport protocol, and decode the transmissions by implementing re-transmission detection logic and message re-assembly logic to process the plurality of transmissions of the file-based transport protocol as a single message. A response may be processed by the virtual file system where the transport layer encodes control data for the response into an input/output (I/O) request packet for transmission via the file-based transport protocol. In encoding the response, control data may be encoded into an upper thirty-two (32) bits of an offset of the I/O request packet for a transmission via the file-based transport protocol. The virtual file system may forward a response to the file-based transport protocol for transmission to the first device. As an example, the file-based transport protocol may be an iteration of Server Message Block (SMB).
In another example, the transport layer of the virtual file system communicates with the file-based transport protocol and a replication engine included in the virtual file system, to process a request. The replication engine may include a replication manager for handling replication requests. The transport layer of the virtual file system may be used to decode the reassembled request by applying data retransmission logic and message assembly logic. The decoded request may be sent to the replication manager for processing. The transport layer may receive a response from the replication manager and encode control data for the response into an input/output (I/O) response packet. The encoded response packet is then and forwarded via the file-based transport protocol.
In another example, an application may be implemented to create a virtual file system on a device. The virtual file system may be used to manage: establishment/disconnection of a connection share of a file-based transport protocol, access control with respect to the connection share, connection loss detection of the connection share, and data transmission to and from the device.
In yet another example, a remote write request is sent from a source device to a target device using a file-based transport protocol as a transport service. The remote write request is processed using a virtual file system, the virtual file system implementing a transport layer to interface with the file-based transport protocol for receiving and evaluating transmissions of the file-based transport protocol. The transport layer may be used to decode control data encoded in an offset and length field of an input/output (I/O) request packet for replication request processing. The decoding may include implementing re-transmission detection logic and message re-assembly logic to process the plurality of transmissions of the file-based transport protocol as a single message. In the decoding, an upper thirty-two (32) bits of an offset for a transmission sent by the file-based transport protocol may be evaluated to detect chunk transferring and data re-transmission. A response is sent, wherein the virtual file system forwards the response to the file-based transport protocol for transmission. Control data may be encoded into an offset and length field of an input/output (I/O) response packet, and sent via the file-based transport protocol. The virtual file system may be used to manage: establishment/disconnection of a connection share of a file-based transport protocol, access control with respect to the connection share, connection loss detection of the connection share, and data transmission to and from a device. As an example, the file-based transport protocol may be an iteration of Server Message Block (SMB).
In an additional example, a computer system may be implemented that includes at least one device for storage replication. The device may be able to send and receive requests and send and receive responses to a request via a file-based transport protocol. The device may be configured to process requests and responses using a virtual file system. The virtual file system may include a transport layer to interface with the file-based protocol for processing data transmitted via the file-based transport protocol. The transport layer of the virtual file system may be configured to encode and decode offset data, including data for applying re-transmission logic and message reassembly logic, into a transmission of the file-based transport protocol. The device may encode the data for applying re-transmission logic and message re-assembly logic into an upper thirty-two (32) bits of the offset when sending a request or response, and decode data for applying re-transmission logic and message re-assembly logic from the upper 32 bits of the offset when receiving a request or response.
Reference has been made throughout this specification to “one example” or “an example,” meaning that a particular described feature, structure, or characteristic is included in at least one example. Thus, usage of such phrases may refer to more than just one example. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more examples.
One skilled in the relevant art may recognize, however, that the examples may be practiced without one or more of the specific details, or with other methods, resources, materials, etc. In other instances, well known structures, resources, or operations have not been shown or described in detail merely to observe obscuring aspects of the examples.
While example examples and applications have been illustrated and described, it is to be understood that the examples are not limited to the precise configuration and resources described above. Various modifications, changes, and variations apparent to those skilled in the art may be made in the arrangement, operation, and details of the methods and systems disclosed herein without departing from the scope of the claimed examples.
