3.8.1 Sockets

• Definition and Use:

  • A socket is an endpoint for communication between two processes on a network.
  • Communication involves a pair of sockets, one for each process.

• Identification:

  • Sockets are identified by an IP address and a port number.

• Client-Server Architecture:

  • Utilizes a client-server model where the server listens on a specified port for client requests.
  • Servers for specific services listen on well-known ports (e.g., SSH on port 22, FTP on port 21, HTTP on port 80).
  • Well-known ports are below 1024.

• Client Connection Process:

  • The client is assigned a port number greater than 1024 by its host for the connection.
  • Example: A connection between a client (146.86.5.20:1625) and a web server (161.25.19.8:80).
  • Each connection is unique; another process on the same host would be assigned a different port number.

• Loopback Address for Testing:

  • The IP address 127.0.0.1 (loopback) is used for communication between client and server on the same host.
  • Loopback allows testing of TCP/IP communication without network infrastructure.

• Communication Characteristics:

  • Sockets enable an unstructured stream of bytes to be exchanged, requiring the application to impose data structure.
  • Sockets represent a low-level form of communication compared to higher-level methods like remote procedure calls (RPCs).

3.8.2 Remote Procedure Calls

• RPC Fundamentals:

  • Designed to abstract procedure calls over networks, similar to Inter-Process Communication (IPC) but for remote systems.
  • Uses structured messages for communication, specifying functions and parameters.

• Communication Process:

  • Messages are addressed to an RPC daemon listening on a specific port on the remote system.
  • RPC communication involves executing a specified function and returning the output to the requester.

• Ports and Daemons:

  • Systems can support multiple network services, each differentiated by unique port numbers.
  • RPC daemons attached to ports enable specific services (e.g., listing current users on port 3027).

• Client-Server Interaction:

  • RPC hides communication details through stubs, which marshal parameters and manage message passing.
  • Windows uses Microsoft Interface Definition Language (MIDL) for defining client-server interfaces.

• Parameter Marshaling:

  • Addresses data representation differences (big-endian vs. little-endian) with machine-independent formats like XDR.
  • Involves converting data into a common format before transmission and back on reception.

• Call Semantics:

  • Unlike local calls, RPCs may fail or duplicate due to network issues. Solutions include “at most once” and “exactly once” semantics.
  • “At most once” uses timestamps to prevent duplicate processing;
    • This semantic can be implemented by attaching a timestamp to each message.
    • The server must keep a history of all the timestamps of messages it has already processed or a history large enough to ensure that repeated messages are detected.
    • Incoming messages that have a timestamp already in the history are ignored.
    • The client can then send a message one or more times and be assured that it only executes once.
  • “exactly once” adds acknowledgments (ACK) to ensure message receipt and execution.
    • we need to remove the risk that the server will never receive the request.
    • To accomplish this, the server must implement the “at most once” protocol described above but must also acknowledge to the client that the RPC call was received and executed.
    • These ACK messages are common throughout networking.
    • The client must resend each RPC call periodically until it receives the ACK for that call.

• Binding and Port Discovery:

  • Binding can be static (pre-determined port numbers) or dynamic (rendezvous mechanism for port discovery).
  • Dynamic mechanism is also called a matchmaker
  • Dynamic binding allows flexibility but adds initial request overhead.

• Use Cases:

  • RPCs facilitate distributed file systems and other networked services by specifying operations like read, write, rename, etc.
  • Android uses RPCs for Inter-Process Communication (IPC) within its binder framework, supporting background services without user interfaces.

• Android Application Components:

  • Services run in the background for long-running operations or network communication.
  • Bound services communicate with client apps using message passing or RPCs, implementing the onBind() method for binding and service provision.

• Android Binder Framework:

  • Handles parameter marshaling, process communication, and method invocation for services.
  • Utilizes Android Interface Definition Language (AIDL) for defining service interfaces and creating stubs for remote service interaction.