Why is GMD Needed?

As discussed in Sockets, connections use (stream) sockets to transmit messages. Sockets have several well-defined, useful features that connections build upon. For example, sockets buffer a fixed amount of data for better performance. The API functions for working with sockets provide an inherently synchronous model. For example, the receive operation by default blocks the receiving process until data is available. The operating system underneath the API is usually very asynchronous. For example, it has interrupt-driven methods to move the socket data from one buffer over the network to another buffer.

Loss of Data When Sockets Fail

When data is sent through a socket, the send operation by default returns as soon as the operating system buffers the data for future delivery over the physical network. The data that is delivered successfully is received in the order it was sent. If there is a network failure, which requires the socket to be closed, such as a node crashing, there is no way for the sending process to know how much, if any, of the data was lost! SmartSockets GMD builds upon the useful properties of sockets and overcomes the deficiencies caused by the limitations of sockets.

Acknowledgment of Delivery

Because of the internally asynchronous nature of stream sockets, GMD needs some way to determine when a message has been successfully delivered. At the socket level, reliable protocols like TCP/IP are built on top of unreliable physical networks where data can be lost, such as Ethernet or serial lines. These network protocols ensure an ordered byte stream by:

Sockets do not provide any capability to notify the sending process that the receiving process has successfully received the data and acted on it. Sockets are thus reliable except when a serious error occurs that requires the socket to be closed. It is this situation where a network programmer most needs to know what data was lost.

GMD also uses acknowledgments in the form of acknowledgment messages. The connection-level acknowledgment messages are different from the socket-level acknowledgment packets, but serve the same purpose: the connection-level function notifies the connection, and the socket-level function is for the operating system. From this point on, the term acknowledgment is used to refer to a SmartSockets-level acknowledgment message, not a socket-level acknowledgment packet.

Alternatives to Stream Sockets

Using stream sockets for any IPC development has both advantages and disadvantages, but in general the advantages greatly outweigh the disadvantages. In TCP/IP networks, the alternative to TCP stream sockets are UDP datagram sockets. UDP is a thin layer on top of IP, which does not provide data retransmission, data acknowledgment, delivery order, or guaranteed delivery. UDP does handle data integrity by adding a checksum to each packet.

It might seem counterproductive to use TCP for SmartSockets GMD because connections have to send acknowledgment messages in addition to the underlying acknowledgment packets going on with TCP. TCP has been deployed for twenty years, though, and many networking experts have worked very hard to tune TCP for optimal performance. If connections used UDP datagram sockets instead of TCP stream sockets, connections would have to reimplement much of TCP. Using reliable network protocols like TCP simplifies GMD because GMD only has to resend messages when network failures occur. Under normal operation, the simpler GMD connection provides good performance because TCP/IP does the job for which it was designed. When network failures occur, connections can not only detect these failures but also use GMD to totally recover from them.