Remote Procedure Call
Birrell and Nelson (1984) introduced a completely different way of handling communication for Distributed System designing. Initially many distributed systems have been based on explicit message exchange between processes. However it was less transparent. So the new concept introduced that is RPC.
Although the idea of communication in RPC is refreshingly simple. In a nutshell, what Birrell and Nelson suggested was allowing programs to call procedures located on other machines. When a process on machine A calls' a procedure on machine B, the calling process on A is suspended, and execution of the called procedure takes place on B. Information can be transported from the caller to the callee in the parameters and can come back in the procedure result. No message passing at all is visible to the programmer. This method is known as Remote Procedure Call, or often just RPC.
While the basic idea sounds simple and elegant, subtle problems exist. To start with, because the calling and called procedures run on different machines, they execute in different address spaces, which causes complications. Parameters and results also have to be passed, which can be complicated, especially if the machines are not identical.
For Example:
Each machine often has its own representation for numbers,characters, and other data items. For example, IRM mainframes use the EBCDIC character code, whereas IBM personal computers use ASCII. As a consequence, it is not possible to pass a character parameter from an IBM PC client to an IBM mainframe server using the simple scheme because the server will interpret the character incorrectly. Similar problems can occur with the representation of integers (one's complement versus two's complement) and floating-point numbers. In addition, an even more annoying problem exists because some machines, such as the Intel Pentium, number their bytes from right to left, whereas others, such as the Sun SPARC, number them the other way. The Intel format is called little endian and the
SPARC format is called big endian. As an example, consider a procedure with two parameters, an integer and a four-character string. Each parameter requires one 32-bit word.What I mean that the parameter portion of a message built by a client stub on an Intel Pentium might look like, The first word contains the integer parameter, 5 in this case, and the second contains the string "JILL."
Each machine often has its own representation for numbers,characters, and other data items. For example, IRM mainframes use the EBCDIC character code, whereas IBM personal computers use ASCII. As a consequence, it is not possible to pass a character parameter from an IBM PC client to an IBM mainframe server using the simple scheme because the server will interpret the character incorrectly. Similar problems can occur with the representation of integers (one's complement versus two's complement) and floating-point numbers. In addition, an even more annoying problem exists because some machines, such as the Intel Pentium, number their bytes from right to left, whereas others, such as the Sun SPARC, number them the other way. The Intel format is called little endian and the
SPARC format is called big endian. As an example, consider a procedure with two parameters, an integer and a four-character string. Each parameter requires one 32-bit word.What I mean that the parameter portion of a message built by a client stub on an Intel Pentium might look like, The first word contains the integer parameter, 5 in this case, and the second contains the string "JILL."
So because of such conflicts either or both machines can crash and each of the possible failures causes different problems. This problems possibly can be avoided by making use of IDL (Interface Definition Language).
Comments
Post a Comment