Q3Distributed System

In traditional networking, programmers are forced to manually open TCP sockets, manage IP addresses, and write complex bit-level parsing code (Socket Programming). This is mathematically tedious and prone to catastrophic buffer overflow errors. Remote Procedure Call (RPC) is an incredibly powerful middleware architecture designed to completely abstract the network away. It allows a developer on Client Node A to write a simple line of code like result = calculate_tax(100) and have that function physically execute on a massive supercomputer Server Node B, while making it mathematically appear to the programmer as if it executed locally on their own laptop.

Because the client and server are physically different machines (they might have different Operating Systems and different CPU Endianness—Little Endian vs Big Endian), passing raw memory pointers is mathematically impossible. RPC solves this using "Stubs," which are auto-generated blocks of proxy code.

• The Client Stub: This code physically resides on the client. When the client application calls calculate_tax(), it is actually calling the Client Stub. The stub's absolute job is Marshalling. It violently grabs the integer 100, converts it into a universally standardized mathematical binary format (like XDR or Protocol Buffers), packages it into a network packet, and blasts it out the Ethernet port.
• The Server Stub: This code physically resides on the server. Its job is Unmarshalling. It violently intercepts the incoming network packet, mathematically unpacks the binary payload back into a local integer, and physically calls the actual server-side calculate_tax() function.

• 1. Invocation: The Client application executes a normal local procedure call, invoking the Client Stub.
• 2. Marshalling: The Client Stub mathematically packs the parameters into a standardized binary message buffer.
• 3. Network Transmission: The Client Stub hands the buffer to the local OS Kernel, which violently fires it across the TCP/IP network to the Server.
• 4. Receipt: The Server OS Kernel physically receives the packet and hands it up to the Server Stub.
• 5. Unmarshalling: The Server Stub unpacks the binary data into memory variables native to the Server's CPU architecture.
• 6. Execution: The Server Stub physically invokes the actual server procedure. The CPU executes the heavy mathematics.
• 7. Reverse Marshalling: The actual procedure returns the result to the Server Stub. The Server Stub mathematically marshals the result into a binary packet.
• 8. Return Transmission: The Server OS blasts the reply packet back across the network to the Client.
• 9. Final Unmarshalling: The Client Stub unpacks the result and hands it back to the waiting Client application.

Throughout this massive sequence, the original Client application was completely blocked (suspended). Once step 9 completes, the application violently wakes up and continues executing, entirely oblivious to the fact that its data just traveled 500 miles across the internet.