RPC OVER RAW ETHERNET

FIELD:

The present Invention discloses a novel method and system for providing a technique by which a network file system can function on top of a data center Ethernet / convergence enhanced Ethernet. In general terms it relates to a distributed computing environment and in particular to a set of computers using remote procedure calls (RPC) to implement a Network File System.

BACKGROUND:

NFS is a popular distributed file system that uses the services provided by the RPC layer which in turn typically uses TCP/IP or UDP/IP to communicate across servers. Typical implementations usually involve a server component that has access to the storage in which files are stored, and a client component that acts on the file by transmitting all the requests to the server. The server would act on the request based on the access rights of the client and respond appropriately. Examples of typical operations are reading the file over network and changing its contents.

However even though implementations over TCP/IP guarantee data delivery, they are processor-heavy and require enormous system bandwidth to perform at line speed and are often limited to sub-line speed as a result of latency introduced by the network. The bandwidth of Ethernet is ahead of the bandwidths of currently available systems including multi-core systems. Thus, Ethernet cards do not transfer data at line speed, introduce latency and consume enormous system bandwidth.

Remote Procedure Calls (RPC) are action requests sent by client and are actually calls to procedures on the server side. RPC transmits the request / data between the client and server using network stack of the host operating system.

RPC allows lossy / lossless transmission modes. Lossless protocols such as TCP introduce latency in the connection, consume a fair amount of network bandwidth and place a lot of overload on the server CPU. On the other hand, lossless protocols such as UDP do not guarantee data integrity rendering them unusable for mission - critical operations.

US patent US6366958 relates to a NETBIOS protocol support for a DCE RPC mechanism. It describes a remote procedure call (RPC) issuing method for network environment which involves executing remote procedure call to server identified by application address using application program interface and NETBIOS protocol. NETBIOS application names are used as though they include a fixed portion representing a machine, and a dynamic portion representing an application on that machine. New functions are provided to use NETBIOS names in place of TCP/IP addresses and these NETBIOS names are then used via the sockets API, leaving RPC's use of the sockets API unchanged.

However, even in this application, the problems related to TCP/IP protocols such as latency and high usage of CPU and network bandwidth also exist with other higher level protocols such as NetBIOS. The current invention works with data link layer directly while preserving the functionality presented by higher layers thus bypassing the problems of latency and increased computing requirements.

US patent US56526483 describes a fast network file system running over a hybrid connectionless transport. It comprises of requesting the protocol layer to send first messages and monitoring the responses from messages. A session-oriented network application dependent on reliable transport of messages on a first system communicates in a new form of connectionless, session-oriented communication called Sideband over a network with a second similar application on a second system. Sideband transport is not guaranteed; some types of messages and those which are lost must be sent on a reliable, non-Sideband transport. The LAN application contains means to track whether Sideband is both available and enabled on its session with the second application. The application determines whether to disable or re-enable the Sideband in its session based on network reliability. As Sideband is fast, but unreliable, the application must be selective about which messages to send Sideband. Messages which would change the state of the receiving system if received twice due to retry of an apparently lost message should not be sent Sideband. The LAN application monitors the responses from the second system to determine whether any messages sent Sideband were lost. In the event of a Sideband message being lost, the application has retry logic which resends the message via a non-Sideband path.

However, this application makes use of the conventional transport layer protocols unlike the present invention. The current invention has an in-built transmission mechanism that is optimized for lossless transport mediums.

US patent US6697878 relates to a computer having a remote procedure call mechanism or an object request broker mechanism, and a data transfer method for the same. The claimed system has a remote immediate data forwarding unit that directs data on physical memory area of auto computer to physical memory area of another computer via network. A computer having a remote procedure call (RPC) mechanism or an object request broker (ORB) mechanism in a distributed computing environment, is constructed comprising a physical memory, a data readout unit for reading out data stored in the physical memory, and a remote direct memory access (RDMA) unit for transferring the data read out by the data readout unit, directly to a physical memory included in a communicating opposite computer which is connected to the particular computer itself through a network, thereby to shorten a delay which is expended on the data transfer between the computers.

However, the said patent described is an implementation of RPC over RDMA. RDMA is a way to reduce the load on the host CPU while transferring data from / to network or other devices and at present uses TCP/IP to handle transactions. It therefore suffers from the disadvantages mentioned above. Further the requirement of costly specialized adapters and the changes required in applications to understand and work with RDMA are another disadvantage.

US patent US6912715 describes a system and method for web-based remote procedure call (RPC). It is a data transmission method in communication network, involves performing transmitting and receiving actions without adding uniform resource locator to
web browser's history list. This invention permits a Remote Procedure Call (RPC) to be executed from a Web page displayed in a standard Microsoft Web browser window, without adding a URL to the Web browser's history list. In one aspect of the invention, an HTML element is used to transmit the HTTP request to the server and a HTML iframe element is used to receive the HTTP response. It utilizes the HTML iframe element such that data is received without adding a URL to the history list. It can be used to build a lightweight Webpage that offers real - time data and interactivity.

However, this application implements RPC over HTTP like application layer level protocols and is aimed at making RPC work over Wide Area Networks such as the Internet.

As is observed from the drawbacks of the above citations, building a lossless transmission layer that is optimized for data center Ethernet as well as the application .running on top of it is required.

SUMMARY:

The present invention is optimized for NFS and is built on the premise that server bandwidth is far more critical than network bandwidth. The primary objective of the invention is to enable Lossless Ethernet as a transport medium for RPC modules. It introduces a new lossless transmission layer optimized for data center Ethernet and the applications running on it

To solve the problem of heavy resource requirements present in the prior art the invention eliminates the need for unreliable protocols such as UDP/IP or heavy protocols such as TCP/IP while providing similar data delivery guarantee using a combination of lightweight protocol and by exploiting some features of the data center Ethernet.

The invention also makes use of the observation that the data link layer has become reliable and additional error detection methods are redundant. Therefore it optionally includes CRC as Ethernet already has a CRC also because the invention would be operating in a controlled environment. Also, the flow control mechanism followed by Ethernet such as PAUSE and Per-priority PAUSE Is utilized in this invention as well.

Some of the recent happenings in Ethernet are the introduction of jumbo frames, PAUSE frames and VLAN tagging, jumbo frames refer to Ethernet frames which carry more than 1,500 bytes and upto 9,000 bytes of MTU (payload). VLAN tagging enables machines located on different segments, to communicate as if they are in the same physical LAN segment The Ethernet which supports these and other new features is generally referred to as Data Center Ethernet or Convergence enhanced Ethernet. The present invention is optimized for present day and future networks that support a larger MTU size, feature hardware flow-control and is expandable across segments.

The flow control provided by Ethernet such as PAUSE frames and priority based PAUSE are used. This negates the need for costly flow control mechanisms in the software such as TCP's sliding window protocol.

In the present application, during a mount operation, the client and server exchange the transport size supported by them along with the other parameters and use that size instead of traditional Ethernet size of 1500, and work on top of Ethernet that can handle these jumbo frames. Further, flow control is managed by the implementation offered by the Ethernet. It also offers a lightweight application-specific protocol to guarantee data delivery and to guard against packet loss in the unusual event. It further relies on Ethernet segments to be grouped together using VLANs to expand the reach and does not require routing or routing protocols such as IP to function.

The present disclosure describes a first embodiment of method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session comprising the steps of obtaining the physical address of the target system, exchanging capabilities with the target system, initializing the communication session with target system, forming data to be transmitted into one or more packets, sending the target system a first value depicting the number of packets to be received, receiving an acknowledgement from said system, transmitting the data
in the form of one or more packets to the said system, sending said system a notification that no more packets are to be received, receiving a second value depicting the number of packets received from said system, comparing said first value to said received second value; and ending said session if said first value is the same as said second value.

The present disclosure also describes a first embodiment of a method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising the steps of obtaining the physical address of the source system, exchanging capabilities with the source system, initializing the communication session with source system, receiving a first value depicting the number of packets of data to be received during the session, acknowledging the receipt of said first value, receiving data in the form of said packets, receiving a notification that no more packets are to be received, generating a second value depicting the number of packets received, comparing said received first value with second value, sending appropriate notification to source system based on the comparison, writing said data to memory if the first value is same as second value; and ending said session

The present disclosure describes a second embodiment of a method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising the steps of obtaining the physical address of the target system, exchanging capabilities with the target system, forming the data into one or more related packets of same sequence, pre-pending a packet header to each of said packets, transmitting said one or more packets, receiving an acknowledgement indicating success or an error message from said system, and retransmitting the sequence on receiving an error message

The present disclosure also describes a second embodiment of a method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising the steps of obtaining the physical address of the target system, exchanging capabilities with the target system, receiving said one or more packets in a sequence each comprising a packet header, comparing the number
of packets received to the information contained in the packet header, sending an acknowledgement or error message to source system based on the comparison, discarding data if the number of packets received is not the same as the information contained in the header, writing said data to memory if the number of packets received is the same as the information contained in the header, and ending said session.

The present disclosure further describes a first embodiment of a device for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising an initializing unit configured to establish and initiate communication and exchange capabilities with the target system, a data packetizing unit configured to form data into one or more packets, a transmission unit configured to send the number of packets to be received as a first value, to send the packetized data and to send an indication of end of transmission, a receiving unit configured to receive number of packets received from the target system as a second value, a processing unit configured to compare said first value to the second value, and a terminating unit configured to end said session if said first value is the same as said second value.

The present disclosure also describes a first embodiment of a device for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising an initializing unit configured to establish and initiate communication and exchange capabilities with the source system, a reception unit configured to receive the number of packets of data to be received during the session as a first value, to receive data in the form of said packets and to receive a notification that no more packets are to be received, a first processing unit configured to calculate the number of packets received as a second value and compare it with said first value, a transmission unit configured to send an appropriate notification based on the comparison, a second processing unit configured to write said data to memory if the first value is same as second value and a terminating unit configured to end said session

The present disclosure describes a second embodiment of a device for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising an initializing unit configured to establish and initiate communication and exchange capabilities with the target system, a data packetizing unit configured to form data into one or more packets of the same sequence prepensed with a packet header, a transmission unit configured to send the packetized data in the form of a sequence, and a receiving unit configured to receive an acknowledgement or error message from the target system;

The present disclosure also describes a second embodiment of a device for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising an initializing unit configured to establish and initiate communication and exchange capabilities with the source system, a reception unit configured to receive data in the form of said packets in a sequence each comprising a packet header, a first processing unit configured to compare the number of packets received with the information in the packet header, a transmission unit configured to send an appropriate notification based on the comparison, a second processing unit configured to write said data to memory if the first value is same as second value, and a terminating unit configured to end said session

BRIEF DESCRIPTION OF THE DRAWINGS:

Some embodiments are described in greater details with reference to the accompanying figures.

FIGURE 1 depicts the network stack representation of the prior art

FIGURE 2 shows the network stack representation of the instant invention

FIGURE 3 shows a method describing the basic functioning of a transmitting device in accordance with an embodiment of the present disclosure

FIGURE 4 shows a method describing the basic functioning of a receiving device in accordance with an embodiment of the present disclosure

FIGURES 5 to 8 explain the normal 10 path and the handling of various error paths

FIGURE 9 shows a method describing the basic functioning of a transmitting device in accordance with a second embodiment of the present disclosure

FIGURE 10 shows a method describing the basic functioning of a receiving device in accordance with a second embodiment of the present disclosure

FIGURES 11 to 14 explain the normal 10 path and the handling of various error paths

DETAILED DESCRIPTION OF THE DRAWINGS:

In order to obviate the above drawbacks the instant invention provides a method and system for providing a technique that implements a distributed file system that functions on top of data center Ethernet. A distributed file system is implemented using the client / server model of communication using RPC (Remote Procedure Calls). The system which stores the file system may also be referred to as the target system which receives and processes the requests originating from a source system. The files are present over the target system and the commands to access them come from the source system in the form of remote procedure calls.

FIGURE 3 illustrates a method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session in accordance with an embodiment of the present disclosure. As seen in Figure 3, the activity is triggered at the source system obtains the address of the target system (101). Ethernet sockets do not have port numbers associated with them as ports are implemented by the transport layer in the ISO OSI network model. Hence applications that run using TCP/IP do not need to know the physical or logical address of the target system. However, applications working directly on Ethernet require the address of the target system. Conventional methods such as TCP/IP may also be used to resolve the target or source system's name and MAC address along with its capabilities. In another embodiment, the MAC address may be obtained from a look up table. This look up table may be formed by adding the physical address and name of each system that forms a
part of the network. Each system coming up advertises its presence by broadcasting its name and address over the network. The other systems which receive this packet respond back with their own names and addresses and are saved in the form of a lookup table comprising name-address pairs.

Next, the source system and target systems exchange capabilities with each other (102). The capabilities may include the size of jumbo frame supported and the timer values to be used during the exchanges. In a preferred embodiment, the target system further sends the agreed upon jumbo-sized message to the source system to test the path. This ensures that the actual data traffic can be handled by the newly enabled code and the networking infrastructure is capable of handling the jumbo frame. If either cannot agree with the other on a particular sized frame or if the path is invalidated to carry the agreed upon jumbo-sized frames, they fall back to the normal mode of communication using TCP/IP. In another embodiment, the target and source systems may further assign unique IDs to each other and send these which would be used during the communication session.

Now, the source system initializes communication with the target system (103). After the initial setup, the target and source system bypass the TCP/IP layer if used and use the MAC address to communicate directly.

The data to be transmitted is formed into one or more packets (104). These packets are of the size of jumbo frames in a preferred embodiment. The maximum size of the payload of the frame corresponds to the size mutually agreed upon during the initialization. In a preferred embodiment, the packets comprise a type field which indicates the application it is meant for. This application is implemented directly over Ethernet. In a preferred embodiment, the packets also have the unique identification ID assigned as part of the capability exchange phase. In yet another preferred embodiment, the packet comprises an offset field depicting the location at which data is to be stored. This eliminates the need for segmentation / reassembly since each packet is self - contained.

This minimizes the need to keep the buffers in memory by making packets self -contained and minimizes the information to be kept in the state machine by just keeping the counters that were not received Instead of timers / complex state transitions.

The number of packets which are going to be transmitted are sent to the target system (105) and an acknowledgment is received for the same (106). Thereafter the data is transmitted in the form of the prepared packets to the target system (107). Hence all the complex processing associated with ensuring proper transmission and reception of data packets has been moved away from data transaction phase or data path into a one-time control transaction phase or control path.

Once the entire set of packets has been sent, the target system is notified that the data transmission is complete (108). It obtains from the target system the number of packets it has received (109). If it is determined that the number of packets sent is the number received (110) i.e. all packets have been received by the target system, then the communication session is closed (111). In a preferred embodiment if the number of packets received is less than the number of sent then the entire set of packets is resent.

FIGURE 4 illustrates a method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session in accordance with an embodiment of the present disclosure. As seen in Figure 4, the activity is triggered at the target system which obtains the address of the source system (201). Conventional methods such as TCP/IP may also be used to resolve the target or source system's name and MAC address along with its capabilities. In another embodiment, the MAC address may be obtained from a look up table. The lookup table may be formed as described above.

Next, the source system and target systems exchange capabilities with each other (202). In a preferred embodiment, the packet size to be used corresponds to the maximum packet size specified by the source system. The maximum frame size and other attributes may be mutually decided upon based on these capabilities as described above. In an embodiment, the target and source systems may further assign unique IDs to each other and send these would be used during the communication session.

Now, the source system initializes communication with the target system (203). After the initial setup, the target and source system bypass the TCP/IP layer and use the MAC address to communicate directly. The number of packets which are expected to be received are obtained from the target system (204) and an acknowledgment is sent for the same (205). Thereafter the data is received in the form of one or more packets from the target system (206). In a preferred embodiment, the packets comprise a^type field which indicates the application it is meant for. This application is implemented directly over Ethernet. In yet another preferred embodiment, the packet comprises an offset field depicting the location at which data is to be stored.

Next, a notification depicting the end of transmission is received (207). The number of packets received are calculated and compared with the value denoting the number of packets which are expected to be received sent earlier (208). It determines if the number of packets received is the same as the number indicated in the initial handshake described as step 204 (209) i.e. if all packets have been received by the target system. If all packets have been received by the system, it sends an acknowledgement of safe receipt and if not, it sends an error message to the source system (210). Once all packets have been received, they are written into memory (211) and the session is ended (212).

FIGURE 9 illustrates a method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session in accordance with a second embodiment of the present disclosure. As seen in Figure 9, the activity is triggered at the source system obtains the address of the target system (301). The methods of obtaining the address have been described above. Next, the source system and target systems exchange capabilities with each other (302). The capabilities may include the size of jumbo frame supported and the timer values to be used during the exchanges. In a preferred embodiment, the target system further sends to the source system the agreed upon jumbo-sized messages to test the path. If the above. In an embodiment, the target and source systems may further assign unique IDs to each other and send these would be used during the communication session.

Now, the source system initializes communication with the target system (203). After the initial setup, the target and source system bypass the TCP/IP layer and use the MAC address to communicate directly. The number of packets which are expected to be received are obtained from the target system (204) and an acknowledgment is sent for the same (205). Thereafter the data is received in the form of one or more packets from the target system (206). In a preferred embodiment, the packets comprise a type field which indicates the application it is meant for. This application is implemented directly over Ethernet. In yet another preferred embodiment, the packet comprises an offset field depicting the location at which data is to be stored.

Next, a notification depicting the end of transmission is received (207). The number of packets received are calculated and compared with the value denoting the number of packets which are expected to be received sent earlier (208). It determines if the number of packets received is the same as the number indicated in the initial handshake described as step 204 (209) i.e. if all packets have been received by the target system. If all packets have been received by the system, it sends an acknowledgement of safe receipt and if not, it sends an error message to the source system (210). Once all packets have been received, they are written into memory (211) and the session is ended (212).

FIGURE 9 illustrates a method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session in accordance with a second embodiment of the present disclosure. As seen in Figure 9, the activity is triggered at the source system obtains the address of the target system (301). The methods of obtaining the address have been described above. Next, the source system and target systems exchange capabilities with each other (302). The capabilities may include the size of jumbo frame supported and the timer values to be used during the exchanges. In a preferred embodiment, the target system further sends to the source system the agreed upon jumbo-sized messages to test the path. If the either cannot agree with the other on a particular sized frame or if the path is invalidated to carry the agreed upon jumbo-sized frames, they fall back to the normal mode of communication using TCP/IP. In another embodiment, the target and source systems may further assign unique IDs to each other and send these which would be used during the communication session.

The data to be transmitted is formed into one or more related packets of the same sequence (303). In a preferred embodiment, each such sequence is assigned a unique identification number. In yet another embodiment, the packet header indicates if the packet is the first, last or only packet in the sequence. It may also indicate if it is all or neither of these. In yet another embodiment, the packet header also indicates the total number of packets in the said sequence. These packets are of the size of jumbo frames in a preferred embodiment. The maximum size of the payload of the frame corresponds to the size mutually agreed upon during the initialization. Each of these packets is pre-pended with a packet header (304). In a preferred embodiment, the packet header comprises the size of the transmission in, for example, number of bytes. In another preferred embodiment, the packet header indicates the sequence identification number to which the packet corresponds. In another embodiment, the packet header indicates the application it is meant for. This application is implemented directly over Ethernet. In yet another preferred embodiment, the packet header indicates the location at which data is to be stored. This eliminates the need for segmentation / reassembly since each packet is self - contained. In yet another embodiment, the packet header indicates the unique IDs assigned to the said system as part of the capability exchange phase.

Thereafter the data is transmitted in the form of the prepared packets to the target system (305).

Once the entire set of packets has been sent, the target system receives either an acknowledgement or an error message (306). In another embodiment, a timer is triggered after sending the entire set of data packets to ensure that the transmitting system can detect errors when one or all the packets are dropped. An acknowledgement indicates that all packets have been successfully received. In the event of an error message the entire set of packets is resent (307).

FIGURE 10 illustrates a method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session in accordance with a second embodiment of the present disclosure. As seen in Figure 10, the activity is triggered at the target system which obtains the address of the source system (401). Conventional methods such as TCP/IP may also be used to resolve the target or source system's name and MAC address along with its capabilities. In another embodiment, the MAC address may be obtained from a look up table. The lookup table may be formed as described above.

Next, the source system and target systems exchange capabilities with each other (402). In a preferred embodiment, the packet size to be used corresponds to the maximum packet size specified by the source system. The maximum frame size and other attributes may be mutually decided upon based on these capabilities as described above. In an embodiment, the target and source systems may further assign unique IDs to each other and send these which would be used during the communication session.

Thereafter the data is received in the form of one or more packets comprising a packet header from the target system (403). In a preferred embodiment, the packet header comprises the size of the transmission in, for example, number of bytes. In another preferred embodiment, the packet header indicates the sequence identification number to which the packet corresponds. In another embodiment, the packet header indicates the application it is meant for. This application is implemented directly over Ethernet. In yet another preferred embodiment, the packet header indicates the location at which data is to be stored. This eliminates the need for segmentation / reassembly since each packet is self - contained. In yet another embodiment, the packet header indicates if the packet is the first, last or only packet in the sequence. It may also indicate if it is all or neither of these. In yet another embodiment, the packet header also indicates the total number of packets in the said sequence.

When a packet indicating the last packet in a sequence in received. The target system determines if the number of packets received is same as the number of packets indicated in a preferred embodiment in the packet header (404) i.e. if all packets of the sequence have been received by the target system. If all packets have been received by the system, it sends an acknowledgement of safe receipt and if not, it sends an error message to the source system (405). In the preferred embodiment a timer may also be used to provide a small delay before sending the error message to provide for out of order packets. If all the packets are not received before expiry of the timer, an error message is sent. If the missing packets are received before expiry of the timer, timer is cancelled and a safe receipt is sent. If all the packets have not been received, the data is discarded (406). Once all packets have been received, they are written into memory (407) and the session is ended (408).

The present invention is not intended to be restricted to any particular form or arrangement, or any specific embodiment, or any specific use, disclosed herein, since the same may be modified in various particulars or relations without departing from the spirit or scope of the claimed invention hereinabove shown and described of which the apparatus or method shown is intended only for illustration and disclosure of an operative embodiment and not to show all of the various forms or modifications in which this invention might be embodied or operated.

The embodiments described above and illustrated in the figures are presented by way of example only and are not intended as a limitation upon the concepts and principles of the present invention. As such, it will be appreciated by one having ordinary skill in the art that various changes in the elements and their configuration and arrangement are possible without departing from the spirit and scope of the present invention as set forth in the appended claims.

We claim:

1. A method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- obtaining the physical address of the target system;

- exchanging capabilities with the target system

- initializing the communication session with target system;

- forming data to be transmitted into one or more packets;

- sending the target system a first value depicting the number of packets to be received;

- receiving an acknowledgement from said system;

- transmitting the data in the form of one or more packets to the said system;

- sending said system a notification that no more packets are to be received;

- receiving a second value depicting the number of packets received from said system;

- comparing said first value to said received second value; and

- ending said session if said first value Is the same as said second value

2. A method as claimed in claim 1, wherein obtaining the physical address of the source system comprises searching for said system in an address look up table, wherein forming said address look up table, comprises:

- broadcasting the name and physical address of the system at which said addresses are to be stored;

- receiving the physical addresses and names of one or more systems which receive said broadcast; and

- storing said received addresses in the form of name-address pairs in said address look up table

3. A method as claimed in claim 1, wherein exchanging capabilities comprise the maximum size of each said packet

4. A method as claimed in claim 1, wherein initializing communication comprises assigning a unique system Identification number to the target system

5. A method as claimed in claim 1, wherein said data is resent if said first value is not the same as said second value

6. A method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- obtaining the physical address of the source system;

- exchanging capabilities with the source system;

- initializing the communication session with source system;

- receiving a first value depicting the number of packets of data to be received during the session;

- acknowledging the receipt of said first value;

- receiving data in the form of said packets;

- receiving a notification that no more packets are to be received;

- generating a second value depicting the number of packets received;

- comparing said received first value with second value;

- sending appropriate notification to source system based on the comparison;

- writing said data to memory if the first value is same as second value; and

- ending said session

7. A method as claimed in claim 6, wherein said exchange of capabilities comprises of sending a packet that matches the maximum size as mentioned by the source system

8. A method as claimed in claim 6, wherein initializing the communication session comprises assigning a unique system identification number to the source system

9. A method as claimed in claim 1 or 6, wherein each said packet comprises a type field depicting the application it is meant for wherein said application is implemented directly over Ethernet

10. A method as claimed in claim 1 or 6, wherein each said packet comprises an offset field depicting the location at which the data is to be stored

11. A method for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- obtaining the physical address of the target system;

- exchanging capabilities with the target system

- forming the data into one or more related packets of same sequence;

- pre-pending a packet header to each of said packets;

- transmitting said one or more packets;

- receiving an acknowledgement indicating success or an error message from said system; and

- retransmitting the sequence on receiving an error message

12. A method for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- obtaining the physical address of the target system;

- exchanging capabilities with the target system

- receiving said one or more packets in a sequence each comprising a packet header;

- comparing the number of packets received to the information contained in the packet header;

- sending an acknowledgement or error message to source system based on the comparison;

- discarding data If the number of packets received is not the same as the Information contained in the header;

- writing said data to memory if the number of packets received is the same as the information contained in the header;

- ending said session;

13. A method as claimed in claim 11 or 12, wherein said packet header comprises a type field depicting the application it is meant for wherein said application is implemented directly over Ethernet

14. A method as claimed in claim 11 or 12, wherein said packet header comprises a size field depicting the number of bytes in the sequence

15. A method as claimed in claim 11 or 12, wherein each sequence is assigned a unique identification number

16. A method as claimed in claim 11 or 12, wherein said packet header comprises an ID field depicting a unique sequence identification number

17. A method as claimed in claim 11 or 12, wherein said packet header comprises a PacketType field depicting if this packet is the first packet in a sequence or last packet in a sequence or neither of the above two.

18. A method as claimed in claim 11 or 12, wherein said packet header comprises an offset field depicting the location at which the data is to be stored

19. A device for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- an initializing unit configured to establish and initiate communication and exchange capabilities with the target system

- a data packetizing unit configured to form data into one or more packets;

- a transmission unit configured to send the number of packets to be received as a first value, to send the packetized data and to send an indication of end of transmission;

- a receiving unit configured to receive number of packets received from the target system as a second value;

- a processing unit configured to compare said first value to the second value; and

- a terminating unit configured to end said session if said first value is the same as said second value;

20. A device as claimed in claim 19, wherein the capabilities comprise the maximum size of each said packet

21. A device as claimed in claim 19, wherein said transmission unit is configured to resend the data if said first value is not the same as said second value

22. A device for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- an initializing unit configured to establish and initiate communication and exchange capabilities with the source system;

- a reception unit configured to receive the number of packets of data to be received during the session as a first value, to receive data in the form of said packets and to receive a notification that no more packets are to be received;

- a first processing unit configured to calculate the number of packets received as a second value and compare It with said first value;

- a transmission unit configured to send an appropriate notification based on the comparison;

- a second processing unit configured to write said data to memory If the first value is same as second value;

- a terminating unit configured to end said session

23. A device as claimed in claim 22, wherein said initializing unit is configured to exchange capabilities by sending a packet that matches the maximum size as mentioned by the source system

24. A device as claimed in claim 19 or 22, wherein each said packet comprises a type field depicting the application it is meant for wherein said application is implemented directly over Ethernet

25. A device as claimed in claim 19 or 22, wherein each said packet comprises an offset field depicting the location at which the data is to be stored

26. A device for lossless transmission of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- an initializing unit configured to establish and initiate communication and exchange capabilities with the target system

- a data packetizing unit configured to form data into one or more packets of the same sequence prepended with a packet header;

- a transmission unit configured to send the packetized data in the form of a sequence; and

- a receiving unit configured to receive an acknowledgement or error message from the target system;

27. A device as claimed in claim 26, wherein the transmission unit is configured to retransmit the sequence if an error message is received

28. A device for lossless reception of data within a network using remote procedure calls directly over Ethernet during a communication session, comprising:

- an initializing unit configured to establish and initiate communication and exchange capabilities with the source system;

- a reception unit configured to receive data in the form of said packets in a sequence each comprising a packet header;

- a first processing unit configured to compare the number of packets received with the Information in the packet header;

- a transmission unit configured to send an appropriate notification based on the comparison;

- a second processing unit configured to write said data to memory if the first value is same as second value;

- a terminating unit configured to end said session

29. A device as claimed in claim 26 or 28, wherein said packet header comprises a type field depicting the application it Is meant for wherein said application is implemented directly over Ethernet

30. A device as claimed in claim 26 or 28, wherein said packet header comprises a size field depicting the number of bytes in the sequence

31. A device as claimed in claim 26 or 28, wherein each sequence Is assigned a unique identification number

32. A device as claimed in claim 26 or 28, wherein said packet header comprises an ID field depicting a unique sequence identification number

33. A device as claimed in claim 26 or 28, wherein said packet header comprises a PacketType field depicting If this packet is the first packet In a sequence or last packet in a sequence or neither of the above two.

34. A device as claimed in claim 26 or 28, wherein said packet header comprises an offset field depicting the location at which the data is to be stored

35. A device as claimed in claim 19, 22, 26 or 28, wherein the initializing unit is configured to obtain the physical address of the target system

36. A device as claimed in claim 19, 22, 26 or 28, wherein the initializing unit is configured to initialize a communication session with the target system

37. A device as claimed in claim 19, 22, 26 or 28, wherein the initializing unit is configured to assign a unique system Identification number to the target system