Distributed Systems Development - Autonomics Development: A Domain-Specific Aspect Language Approach - page 13

if (connect(sock, (struct sockaddr ∗) &server,
sizeof(server)) < 0) {
fprintf(stderr, "connect failed\n" );
exit(1);

}

char buf [512];

readline(sock, buf, sizeof(buf));
printf( "The time on the server is: %s" , buf);
close(sock);
exit(0);

}

In both the client and the server examples above, the code that is used
to either obtain the date or receive it is shaded in grey, while the other code
implements the distribution concern.

2.2.3 Summary

Socket-based programming is highly complex and error prone. Developers need
to implement message-based protocols on top of the socket interface with the
resultant complexity directly proportional to the protocol requirements.
As illustrated in our simple example, socket-based programming is highly
intrusive, even for simple applications. Programmers need to adhere to the socket
API throughout the application and ensure that reads from sockets and writes to
sockets return the number of bytes requested or the number of bytes required to
be written respectively.
The most common protocols used in socket programming are TCP/IP and
UDP/IP. UDP is a datagram protocol, which does not provide guaranteed message
delivery or duplicate elimination. Although TCP/IP provides these features it
does not guarantee message delivery in all circumstances [23, 115]. If guaranteed
message delivery is a protocol requirement, it will need to be provided by the
protocol developer. Protocol reliability is discussed in detail in Section 2.3.4.
Recovery is left up to the programmer to implement at a very low level
and any significant recovery routines, for example connecting to another server
in the event the current server becomes unavailable, will have to be implemented
wherever a remote call is made, thereby further complicating development.

2.3 Remote Procedure Calls
In order to provide an environment with the simplicity of the then dominant proce-
dural programming paradigm, Birrell and Nelson [15] suggested the use of remote
procedure calls (RPC). The idea of RPCs is based on the observation that proce-
dure calls are a well-known and well-understood mechanism for transfer of control
and data within a program running on a single system and that this mechanism