Problems with the current API
Major problems:
- When receiving a multiaddress (e.g. from an address record in the DHT), we immediately try to parse it. If parsing fails, that multiaddress is discarded. Parsing fails if the multiaddress contains any unknown components: if a node hasn’t been updated to understand WebTransport addresses, it won’t be able to parse a WebTransport multiaddress, and won’t be able to forward it to other (WebTransport-enabled) nodes.
Related: multiformats/multiaddr#155
Minor problems:
Multiaddr is an interface, and therefore (almost always) allocated on the heap. This creates a lot of GC pressure.- Methods are split between packet-level functions (e.g.
SplitLast) and methods on the interface (e.g. ValueForProtocol). There’s no (apparent) logic behind this, making use of the API confusing
- The methods weren’t designed with allocations in mind. One of them (especially
Protocols) is the major source of allocations in a Kubo node
Tasks
Problems with the current API
Major problems:
Related: multiformats/multiaddr#155
Minor problems:
Multiaddris an interface, and therefore (almost always) allocated on the heap. This creates a lot of GC pressure.SplitLast) and methods on the interface (e.g.ValueForProtocol). There’s no (apparent) logic behind this, making use of the API confusingProtocols) is the major source of allocations in a Kubo nodeTasks