What is the difference between Socket and RPC?

Question

What is the actual difference between Socket and RPC (Remote Procedure Call)?

As per my understanding both's working is based on Client–server model. Also which one should be used in which conditions?

PS: Confusion arise while reading Operating System Concepts by Galvin

Solution 1

Short answer:

RPC is the protocol. The socket provides access to the transport to implement that protocol.

RPC is the service and protocol offered by the operating system to allow code to be triggered for running by a remote application. It has a defined protocol by which procedures or objects can be accessed by another device over a network. An implementation of RPC can be done over basically any network transport (e.g. TCP, UDP, cups with strings).

The socket is just a programming abstraction such that the application can send and receive data with another device through a particular network transport. You implement protocols (such as RPC) on top of a transport (such as TCP) with a socket.

Solution 2

It is operating system specific. So read first a good OS book like Operating Systems: Three Easy Pieces (freely downloadable).

Network sockets are a way to do some inter-process communication (notably between different machines). Read also about Berkeley sockets API, e.g. socket(7) on Linux.

Remote procedure calls are a programming technique (often using socket(2) system call on Linux). Every RPC request expects exactly one reply and is software initiated.

Sockets are often also used for asynchronous messages (for example, the X11 protocols stack, WebSockets, SMTP). Message passing is a programming paradigm (more general than RPC), they are sent often without expecting any reply. For example, the X11 server would send a keyboard event message for every key press, etc.

^{(so in some ways, you are comparing apples and oranges)}

If on Linux, I recommend reading Advanced Linux Programming (freely downloadable), and reading more about syscalls(2) (notably poll(2) for multiplexing)

Solution 3

PS: Confusion arise while reading Operating System Concepts by Galvin

That's your problem right there.

A remote procedure call (RPC) is high level model for network communication. There are numerous RPC protocols in existence. In the RPC model, your underlying implementation creates a stub for each remote procedure. When your application calls the "remote procedure" the stub packs up the parameters, sends them over the network, invokes, the remote version of the procedure, takes the return values and send them back over the network to the caller, the stub unpacks the return values and your application then receives them.

The RPC model became hip in the late 1980's. The idea was that it would be transparent where your functions actually executed (in your process, in another process, on another computer). This concept expanded into distributed objects around the early 1990's (e.g., DCOM, CORBA).

Unfortunately, in the real world applications really needed to know if a procedure was executing remotely because of delay and error handling.

Somewhere in the the RPC implementation a network interface gets called.

Sockets are such a network interface. They are not the only programming interface but they are the most common on Unix systems.

Thus, an RPC MIGHT be implemented using a socket.