基于XDR语言的RPC跨主机通信：如何实现字节序与指令集无关？

Great question—this is exactly why XDR was designed in the first place! Let’s break down the key mechanisms that let XDR abstract away byte order, instruction set, and memory layout differences between hosts:

1. A Canonical, Host-Neutral Data Format #

XDR defines a strict, universal "canonical" format for every data type it supports. No matter what architecture you’re on, all data is converted to this standard before being sent over the wire:

• Integers (32-bit, 64-bit) are always stored in big-endian byte order
• Floating-point numbers use the IEEE 754 standard (single/double precision)
• Strings and arrays are prefixed with a 32-bit length value, followed by the raw data (no padding unless required for alignment)
• Structures are serialized in the exact order their fields are defined in the XDR specification, with no compiler-specific padding bytes

This means a value like 0x12345678 (a 32-bit int) will always be sent as the byte sequence 0x12 0x34 0x56 0x78, regardless of whether the sender uses little-endian (x86/x86_64) or big-endian (PowerPC, older ARM) hardware.

2. Mandatory Serialization/Deserialization Stubs #

XDR doesn’t let you send raw memory dumps over RPC. Instead, every RPC call uses client and server stubs—auto-generated code that handles the conversion between local host data and XDR format:

• On the client side: The stub takes your local data structures (in whatever byte order/memory layout your host uses) and converts them to XDR’s canonical format before transmitting.
• On the server side: The stub receives the XDR-formatted data, converts it back to the server’s local byte order and memory layout, then passes it to the actual server function.

This conversion is completely transparent to developers—you just work with your native data types, and the stubs handle the messy cross-architecture translation.

3. Abstract, Instruction-Set-Agnostic Type Definitions #

XDR’s type system isn’t tied to any specific CPU or instruction set. For example:

• An XDR int is explicitly a 32-bit signed integer, not the "native int" of your compiler (which might be 16, 32, or 64 bits depending on the host)
• Structures are defined with fixed field sizes and order, ignoring compiler-specific memory alignment rules (like padding bytes added between fields to optimize CPU access)

When serializing, XDR strips out any host-specific padding; when deserializing, it adds back whatever padding the receiving host’s compiler expects. This ensures that even if two hosts use completely different memory layout rules, the structure data is interpreted correctly.

Quick Example to Illustrate #

Let’s say you’re on a little-endian x86 machine sending the integer 12345678 to a big-endian PowerPC server:

1. Your local x86 stores the int as bytes 0xEF 0xCD 0xAB 0x00 (little-endian)
2. The client stub converts this to XDR’s big-endian format: 0x00 0xAB 0xCD 0xEF
3. The server receives this byte sequence, and since it’s big-endian, the server stub can pass it directly to the server function without conversion
4. If the server were another little-endian machine, the stub would convert the XDR bytes back to 0xEF 0xCD 0xAB 0x00 before use

In short, XDR acts as a universal "translation layer"—it takes host-specific data, converts it to a neutral format for the wire, then converts it back to the target host’s native format on the other end.

内容的提问来源于stack exchange，提问作者Harsha