IRIDIUM is a low-level networking protocol that sits underneath both MERCURY for inter-cluster and WOLFRAM for intra-cluster communications; it is not directly accessible to user code. It's implemented in CHROME as CHROME does not depend upon it, so it can be! As an ARGON system component, it has access to the basic networking interfaces of HYDROGEN, which may either be raw Ethernet interfaces (in which case it has to provide an IP stack as well, shared with FLUORINE); or on "hosted" HYDROGEN platforms, it will be given access to higher-level "IP address" devices that wrap the underlying TCP/IP stack.

It provides both connectionless and virtual-circuit communication of arbitrarily sized messages between nodes, offering flow control, retransmission, bandwidth reservation (where available), and optional sequencing of messages within a virtual circuit. It also provides for the recipient of a message to reply, with the reply and the acknowledgement of receipt of the original request being carried together, and the reply being automatically tied to the request.

I've written on my blog about the rationale for IRIDIUM.

I plan to implement it on top of UDP for Internet use, and on top of raw byte streams for use over point-to-point links (with full bandwidth reservation capability) before long to provide real time networking.

It is a design requirement that small requests should be tranmissable in a single UDP datagram, with no requirement to negotiate any kind of connection with the server, and that small responses should likewise fit in a single UDP datagram. This is to minimise the latency for various common message transactions.

Consider a DNS server; a single UDP datagram containing a request comes in, and the response goes out as a single UDP datagram. There is no need to establish any connection state with the DNS server beforehand. Therefore, DNS servers manage to serve a vast number of clients with very little resource usage, and very low latency.

I've written a draft specification for IRIDIUM( on my blog!