Faces & transports
A face is an NDN-layer link; the transport underneath it is a separate choice. The same Interest and Data ride any of them unchanged, so picking a transport is about your deployment, not your protocol. Start from where the two ends are.
| The two ends are… | Reach for | What it costs |
|---|---|---|
| Two processes on one host | Unix socket, or shared memory extension (spsc-shm) | shm is the fastest path but same-host only; Unix sockets are simpler and still local. |
| Across a network, general purpose | UDP (default) or TCP | UDP is the common, cross-implementation choice; TCP adds head-of-line blocking but traverses some middleboxes better. |
| A browser tab and a forwarder | WebSocket or WebTransport extension | Needs a listener and (for WebTransport) a cert; browser-side only. |
| Two browsers / NAT-bound peers | WebRTC extension | Requires signaling/relay infrastructure to establish the channel. |
| Constrained radio, no IP | BLE or Wi-Fi Aware extension | Small MTUs force NDNLPv2 fragmentation; throughput and range are limited. |
| Max throughput on a Linux NIC | Ethernet, or AF_XDP extension (af-xdp feature) | AF_XDP is Linux-only kernel-bypass — fastest, but ties you to that platform and a raw NIC. |
How to decide
- Same host? Use Unix sockets; reach for shared memory only when you have measured the local path as a bottleneck.
- Interoperating with other NDN forwarders? Stay on UDP/TCP — they are the lingua franca.
- In a browser? WebSocket is the low-friction start; WebTransport when you need datagrams and have the cert plumbing.
- On a radio without IP? BLE or Wi-Fi Aware, and budget for fragmentation overhead at small MTUs.
- Chasing line rate on Linux? Ethernet, then AF_XDP — but only after the ordinary path is proven too slow (Reliability & throughput).
The full per-transport catalogue — URIs, MTUs, scopes — is in Face transports. To add a bearer of your own, see Implementing a face.