Before your eyebrows raise too much, i know TIPC may be unfamiliar outside the esoteric realm of "cluster computing on linux", so a quick bit of context.
This is not a new or experimental transport ✌🏼
Transparent Inter-Process Communication was developed by Jon Maloy and the TIPC team at Ericsson (yes the same entity responsible for the EVM and friends) for carrier-grade cluster applications, was presented at the 2004 Linux Symposium, and was merged into mainline Linux on 2 January 2006. It has therefore been an in-tree Linux networking subsystem for twenty years.
It is sometimes called Cluster Domain Sockets, which captures the
idea well: the Linux docs introduce it as the convenience of Unix
domain sockets extended across cluster nodes. An application binds a
location-independent service name, the kernel publishes it in a
cluster-wide name table, and clients connect by that name without an
IP address, DNS name or transport port.
I am implementing TIPC as a transport for distributed Python
processes in goodboy/tractor#493. The current prototype
uses an interim string form because /tipc is not registered with
multiaddr:
/tipc/<service-type>/<instance>/<scope>
The composed form I ultimately care about is a TIPC service reached
through a WireGuard bearer:
/ip4/<public-ip>/udp/51820/wg/u<key>/tipc/<service-name>
Unlike TCP-over-WireGuard, TIPC deliberately has no inner IP/port:
the wg portion identifies the bearer and peer, while TIPC's kernel
name table resolves the service to whichever cluster node currently
publishes it.
SO,
Would the project be open to a draft tipc codec implementation,
following the prototype-first path used for wg in #107 / PR #108?
I would especially value maintainer review before treating any of
these choices as settled:
- one structured text value, currently proposed as
<type>:<instance>:<scope>, versus another existing multiaddr
convention, which please do suggest alts if there are options 🙏🏼
- a fixed nine-byte binary value (
uint32be type, uint32be instance, uint8 scope) versus a variable/self-describing tuple
- whether a generally shareable address should admit node scope or
only cluster scope: the kernel UAPI defines these as publication
scopes, while the TIPC addressing guide
distinguishes node-local from cluster-global binding visibility
- whether this endpoint protocol should represent singleton service
names only, leaving TIPC service ranges to a separate concern
- when to reserve a multicodec and submit the eventual multiaddr spec
I am happy to implement the codec, deterministic vectors, malformed
input coverage and standalone/composed round trips. My preference is
to let review of that concrete Python implementation shape the later
registration plan, as happened with the follow-up work in #123 and
#130, rather than presenting an unfamiliar protocol as a finished
specification up front.
Primary references:
I realize this one is a bit of strange ask (given that noone i've talked to in the conc-eng space seems to have heard of this proto despite its age 😂) but i'd very much appreciate some feedback and am obvi very happy to adjust the prototype around the project's
preferred codec and registration conventions.
Before your eyebrows raise too much, i know TIPC may be unfamiliar outside the esoteric realm of "cluster computing on linux", so a quick bit of context.
This is not a new or experimental transport ✌🏼
Transparent Inter-Process Communication was developed by Jon Maloy and the TIPC team at Ericsson (yes the same entity responsible for the EVM and friends) for carrier-grade cluster applications, was presented at the 2004 Linux Symposium, and was merged into mainline Linux on 2 January 2006. It has therefore been an in-tree Linux networking subsystem for twenty years.
It is sometimes called Cluster Domain Sockets, which captures the
idea well: the Linux docs introduce it as the convenience of Unix
domain sockets extended across cluster nodes. An application binds a
location-independent service name, the kernel publishes it in a
cluster-wide name table, and clients connect by that name without an
IP address, DNS name or transport port.
I am implementing TIPC as a transport for distributed Python
processes in goodboy/tractor#493. The current prototype
uses an interim string form because
/tipcis not registered withmultiaddr:
The composed form I ultimately care about is a TIPC service reached
through a WireGuard bearer:
Unlike TCP-over-WireGuard, TIPC deliberately has no inner IP/port:
the
wgportion identifies the bearer and peer, while TIPC's kernelname table resolves the service to whichever cluster node currently
publishes it.
SO,
Would the project be open to a draft
tipccodec implementation,following the prototype-first path used for
wgin #107 / PR #108?I would especially value maintainer review before treating any of
these choices as settled:
<type>:<instance>:<scope>, versus another existing multiaddrconvention, which please do suggest alts if there are options 🙏🏼
uint32be type,uint32be instance,uint8 scope) versus a variable/self-describing tupleonly cluster scope: the kernel UAPI defines these as publication
scopes, while the TIPC addressing guide
distinguishes node-local from cluster-global binding visibility
names only, leaving TIPC service ranges to a separate concern
I am happy to implement the codec, deterministic vectors, malformed
input coverage and standalone/composed round trips. My preference is
to let review of that concrete Python implementation shape the later
registration plan, as happened with the follow-up work in #123 and
#130, rather than presenting an unfamiliar protocol as a finished
specification up front.
Primary references:
net/tipcimplementationI realize this one is a bit of strange ask (given that noone i've talked to in the conc-eng space seems to have heard of this proto despite its age 😂) but i'd very much appreciate some feedback and am obvi very happy to adjust the prototype around the project's
preferred codec and registration conventions.