Blog Index

iroh 0.22.0 - Cleanup on aisle five

by dig

Welcome to a new release of iroh, the open-source distributed systems toolkit with tools for direct connections, moving data, and syncing state.

In v0.22, we’ve focused on fixing bugs and adding stability.

🏞️ Improved Handling of Existing Local Content

We've untangled a few subtle interactions in the downloader in this release. These interactions involved attempting to download content that you already had and attempting to download content from yourself.

Previously, if you tried to download a blob that you already had, the blob downloader would first attempt to open connections to peers before checking if you already had this blob locally. That process is now reversed: we check if you have a blob or collection locally before attempting to download it.

The second, more insidious, bug happened when your own NodeId was listed as a potential provider of the content you were trying to download. Now, if your own NodeId is the only listed provider, the download will fail with the “No Providers” error.

For more information, checkout PR #2586.

🚊 Fix regression: Fast direct connections

In iroh, we relate many different addresses to one NodeId and we send data over the lowest latency path to that NodeId.

Previously, we would wait until we knew the latency of a node's direct address before we attempted to send to that address. In many scenarios, specifically the ones where we would need to hole-punch before being able to connect directly anyway, waiting for the Ping/Pong process to determine the latency was fine.

However, there are real scenarios where you already know the public direct address of the node you want to talk to. In this case, the connection should be instant since you know that no hole-punching is needed to establish a direct connection.

The changes in this release make that possible. If you know that a node has a direct, public address, when you supply that address using a NodeAddr, iroh will now immediately attempt to connect to that address.

For more information, checkout PR #2580.

🔁 More Robust Gossip Dispatcher

We’ve made some changes in iroh-gossip to ensure we close and clean up connections safely and reliably.

The net::Gossip struct now tracks the client-side subscribers per topic. The topic will quit once all the handles to a GossipTopic are dropped.

This change completely removes the iroh_gossip::dispatcher and pulls most of those APIs into the GossipTopic. These APIs are not yet stable and may undergo another round of changes as we work with iroh_gossip more.

See below for the specific adjustments that need to be made to upgrade iroh-gossip.

Check out PR #2570 for more details.

⚠️ Breaking Changes

Protocol Changes

API Changes

  • iroh-gossip

    • iroh_gossip::dispatcher is removed with everything that was in it. Use the new API from iroh_gossip::net::Gossip instead (see below).
    • iroh_gossip::net::Gossip methods changed:
      • changed: join now returns a GossipTopic
      • removed: broadcast, broadcast_neighbors, subscribe, subscribe_all, quit.
        • for subscribe use join instead, which returns a GossipTopic
        • for broadcast and broadcast_neighbors use the respective methods on GossipTopic .
        • quit is obsolete now, the topic will be quitted once all GossipTopic handles are dropped.
        • subscribe_all is no longer available
    • iroh_gossip::net::JoinTopicFut is removed (it is now obsolete)
  • iroh-net

    • Refactored the module structure for users of the iroh-relay feature in iroh-net
      • moved
        • iroh_net::relay::iroh_relay::* to iroh_net::relay::server::*
        • iroh_net::relay::ClientConnHandler to iroh_net::relay::server::ClientConnHandler
        • iroh_net::relay::Metrics to iroh_net::relay::server::Metrics
        • iroh_net::relay::MaybeTlsStreamServer to iroh_net::relay::server::MaybeTlsStreamServer
        • iroh_net::relay::http::Client to iroh_net::relay::HttpClient
        • iroh_net::relay::http::ClientBuilder to iroh_net::relay::HttpClientBuilder
        • iroh_net::relay::http::ClientReceiver to iroh_net::relay::HttpClientReceiver
        • iroh_net::relay::http::ClientError to iroh_net::relay::HttpClientError
        • iroh_net::relay::http::TlsConfig to iroh_net::relay::server::TlsConfig
      • removed iroh_net::relay::http::ServerHandle. The server can now be aborted via its task_handle() function or by dropping it.
      • renamed iroh_net::relay::RelayClient to iroh_net::relay::RelayConn
      • renamed and moved iroh_net::relay::Server to iroh_net::relay::server::ServerActorTask
      • unexposed iroh_net::relay::http::{Server, ServerBuilder}. Use iroh_net::relay::server::Server instead.
    • Properly feature-gate the iroh server implementation behind #[cfg(feature = "iroh-relay")] by feature-gating the whole iroh_net::relay::server module.
  • iroh

    • Unknown fields in the configuration file will now cause an error.
    • Configuring the GC Policy in the configuration file has changed.
      • Example:
    [gc_policy]
    enabled = true
    interval = 1234
    

But wait, there's more!

Many bugs were squashed, and smaller features were added. For all those details, check out the full changelog: https://github.com/n0-computer/iroh/releases/tag/v0.22.0.

If you want to know what is coming up, check out the 0.23.0 milestone, and if you have any wishes, let us know about the issues! If you need help using iroh or just want to chat, please join us on discord! And to keep up with all things iroh, check out our Twitter.

Iroh is a dial-any-device networking library that just works. Compose from an ecosystem of ready-made protocols to get the features you need, or go fully custom on a clean abstraction over dumb pipes. Iroh is open source, and already running in production on hundreds of thousands of devices.
To get started, take a look at our docs, dive directly into the code, or chat with us in our discord channel.