The IRI team has been hard at work the past couple months on increasing the stability of the software, and making it better prepared to accommodate the growth in adoption of IOTA. The previous release, IRI 1.7.1, brought multiple fixes that made the software more stable. Making IRI future-proof also meant rethinking some components of the software completely. One of the components that we rewrote completely, and released today, is networking.

The networking rewrite brings with it a ton of changes that will make the node behavior better prepared for what’s ahead. It also simplifies the way the node software works so the code is more adaptable, and easier to debug. We have also added things like BCTCurl into the transaction processing pipeline, and IRI can now hash transactions in batches of up to 64. This will tie into the throughput improvements that will follow.

Thanks to the IOTA community committee

Part of this effort was setting up an IOTA community committee. A group of community members that were voted in by the rest of the community. The members provided oversight and feedback on the changes and participated with their own nodes in a network to test the new networking on.

Thanks to Mathieu Viossat, muXxer, nuriel77, Roman Semko, Yell0w, and Zoran. And to IF’s Luca Moser for setting up and maintaining the network.

We hope to use a similar approach with some larger future changes as well.

Upgrading to 1.8.0

To keep participating on Mainnet, you will need to upgrade your node. This release is not backward compatible.

To upgrade your node:

Change your neighbor connections from UDP to TCP. UDP is not supported by the new release. If you have a neighbor with whom you have not switched to TCP yet, please reach out and make the change. Change the configuration parameters as described in the Changes in 1.8.0 section. Download the new version of IRI from the release page. Run the new version of IRI.

Please leave some time for your neighbors to upgrade. Connection will only be established with neighbors who upgraded to 1.8.0. If you are not receiving traffic from your neighbors within a day, restart your node. Your neighbors may have upgraded after a longer period of time and restarting your node should allow the node to re-establish the connection.

Changes in 1.8.0

There are many, many changes in this version, but they are all confined to the networking layer. The notable changes are:

Support for UDP connections has been removed

The following configuration parameters have been removed:

UDP_RECEIVER_PORT

TCP_RECEIVER_PORT

MAX_PEERS

DNS_REFRESHER_ENABLED

DNS_RESOLUTION_ENABLED

The following configuration parameters have been added:

NEIGHBORING_SOCKET_ADDRESS — defines the socket address to bind the TCP socket to.

defines the socket address to bind the TCP socket to. NEIGHBORING_SOCKET_PORT — defines the port of the TCP socket to use.

defines the port of the TCP socket to use. RECONNECT_ATTEMPT_INTERVAL_SECONDS — defines the interval at which to try to reconnect/disconnect wanted neighbors.

— defines the interval at which to try to reconnect/disconnect wanted neighbors. AUTO_TETHERING_ENABLED — controls auto-tethering, this was previously controlled via `TESTNET` true, default is false (also in testnet mode).

— controls auto-tethering, this was previously controlled via `TESTNET` true, default is false (also in testnet mode). MAX_NEIGHBORS — rename of MAX_PEERS, defines the max number of connected neighbors. Default is 5, the previous parameter had a default of 20.

Other notable changes:

It is now possible to connect to multiple neighbors originating from the same IP address, as the identity of a node is its IP address + server socket port

BCTCurl is used within the transaction processing pipeline which batches up to 64 transactions to hash them at the same time.

Neighbors are now only added after their domain name could be resolved.

Gossiping transaction messages are now dynamic and take 341–1650 bytes of data.

The getNeighbors API call now also returns the domain with which the neighbor was added and whether the neighbor is actually connected.

The requested transaction hash of a transaction gossip packet is now fixed to 49 bytes, no matter in what mode the node runs in.

You can find the full list of changes on the release page.

What’s next

With the new networking in place, the IRI team will now focus on improving the overall throughput of the network. This starts with adding a caching layer on top of our IRI database to avoid unnecessary I/O. This should significantly improve the CTPS that we are able to support. We will then expand on that change as necessary.

Join the IOTA Discord server here.