CSCE-533 | Message passing based IPC

All communication in distributed systems is based on explicit message exchange (sending and receiving messages).

When process P wants to communicate with process Q, it

Construct a message in its own address space.

Execute a system call, which sends the message through the network to process Q.

What if the network is unreliable, and message is lost?

Then receiving process Q handles the messsage asynchronously or synchronously based on the communication model .

IF a server receives the connection message, server must responds with the acknowledgment.

Distributed system with no shared memory.

Types of communication:

1. Persisten communication:
2. A message that has been submitted for transmission is stored by the communication middleware as long as it takes to deliver it to the receiver.
3. Transient Communication
4. A meesage is stored by the communication system only as long as the sending and receiving application are executing.

An analogy of Email vs Phone Call:

• Persistent = Email
• Message stored by email server until recipient reads it
• Recipient doesn't need to be online when sent
• Email server handles storage/delivery
• Transient = Phone Call
• Communication only works if both parties are active
• No storage if recipient unavailable
• Message lost if connection drops

In distributed systems if a message is lost during network communication between processes P and Q, several key challenges arise:

1. The sender (P) has no reliable way to know what happened because failures are indistinguishable:
2. Network could have lost the message
3. Message could be delayed/slow due to congestion
4. Receiving process Q could have crashed
5. Q could be slow in processing
6. Q could be compromised/misbehaving
7. This leads to fundamental assumptions in distributed systems:
8. Partial failures are inevitable and common
9. Network latency is unbounded (no guaranteed delivery time)
10. Solutions typically involve:
11. Using acknowledgments (ACKs) from receivers
12. Implementing retry mechanisms
13. Building failure detection systems
14. Using persistent communication when needed (middleware stores messages until delivery)
15. Employing transient communication where appropriate (messages only stored while both processes are running)

The key challenge is that in a distributed system with only message-passing (no shared memory), it's impossible to definitively determine why a message wasn't received, making failure handling complex but essential.

Common IPC methods in distributed systems:

1. Sockets (TCP/UDP)
2. Rest APIs
3. Remote Procedure class

Yes, a socket is an interface/abstraction that sits between the transport layer (TCP/UDP) and application layer. It provides APIs for applications to use transport layer services:

Application Layer
 ↕️ Socket Interface
Transport Layer (TCP/UDP) 

Socket is the door to the application. We can have different types of socket. Which OS uses pid to identify which door to supply the requested information.

Web Server (PID 1234)
Socket: 192.168.1.1:80 (listening)
Client: 10.0.0.1:45678

Full socket ID: TCP:192.168.1.1:80:10.0.0.1:45678

• Port 80 is reserved for HTTP (not HTTPS).
• HTTPS uses port 443 by default.

Yes, without sockets you'd need to manually handle raw network protocols like constructing TCP/IP packet headers, managing IP addressing, setting checksum values, handling network byte ordering.

We also need to deal with low-level operations likes buffer management, packet fragmentation/assembly, error detection/correction, flow control

Not only that but also deal with direct network device access, memory management, interrupt handling.

Whom should we thank for Socket Development?

Berkeley Sockets (BSD Sockets) were developed at UC Berkeley in the early 1980s as part of BSD Unix. Key developers included Bill Joy and Sam Leffler. The API became standardized as part of POSIX and is now the standard networking interface across most operating systems.

This standardization helped drive widespread adoption of TCP/IP and influenced modern internet development.