Skip to main content
GLink is a generic link-layer transport. It gives clients the same high-level channel API while transport plug-ins adapt that API to Shared Memory / RPM or another physical link. GLink is peer-to-peer and symmetric: either endpoint can open channels, exchange data, and participate in negotiation. A channel is a discrete logical data pipe, and multiple channels can share one physical transport. The core owns channel state, command processing, buffer ownership, and client notifications. The transport plug-in marshals commands and data into the wire format required by the physical transport. A plug-in can also translate GLink commands when the remote endpoint does not run the same GLink implementation.

​
Receive intents provide back-pressure

Before a peer transmits, the receiving client queues a receive intent with the maximum packet size it can accept. The remote GLink core learns that an eligible buffer exists and selects a matching intent when data is sent. Intents provide back-pressure without requiring a separate credit protocol. They also let a copy-based transport reserve space or allocate a receive buffer before the physical transfer starts. A client can queue multiple intents, and the sender uses the first suitable intent.

​
Channel lifecycle

Opening a channel identifies the transport, remote edge, and channel name. The channel is usable only after the remote endpoint accepts the open request and the client receives a connected notification. The main state notifications are:
  • Connected – Both endpoints completed channel setup.
  • Local disconnected – The local client requested close and cleanup is complete.
  • Remote disconnected – The remote endpoint closed the channel first.
After local disconnection, no additional channel activity occurs and callback resources can be released. Re-establishing communication requires opening the channel again.

​
Negotiation and transport selection

When a transport comes up, both endpoints negotiate a compatible protocol version and feature set. Each side starts from its highest supported version, exchanges a version command and acknowledgement, and reduces the selection when the peer supports less. Feature flags are negotiated for the selected version, normally by intersecting supported features. The transport is not considered open until both negotiation sequences finish. GLink can also select the best available transport for an edge using transport priority and optional client selection information.

​
Buffer ownership

Ownership follows the asynchronous operation:
  1. The receiving GLink owns a queued intent while it is available for a transfer.
  2. The sending client submits data.
  3. The receiving client processes the buffer and signals completion.
  4. The sending side receives notification and can reuse or release its transmit state.
Close and subsystem-restart paths must return both receive-intent and transmit-packet private data through abort callbacks.

​
Next steps

  • Use Cases — Open channels, send and receive data, handle subsystem restart
  • Debugging — Diagnose transport state, channel state, and buffer ownership issues