# Client libraries and IRI with networking rewrite update

Many things have been baking in our IRI and client lib development efforts the past few months and I feel like it is time for another update to highlight what is coming. If you are an IRI node operator, then please do read on. We will go over some of the breaking changes coming with the networking rewrite.

We have released the stateful versions of client libraries back in April. Since then we have worked on improving the documentation and most recently, we have started ramping on the new MAM protocol.

MAM will also be the focus of the upcoming weeks. All the libraries — Java, JS, and Go will provide wrappers for the new MAM protocol that has been in the works for a few months now. You can take a look at the alpha of the new MAM here.

A lot has been happening in IRI. There is a version 1.7.1 coming next week. This version introduces a large number of different fixes and changes. One of the fixes we believe should improve the issue where the node got stuck at ‘repairing corrupted milestone. This issue has proven very difficult to debug.

Another important change in IRI is a new tip selection timeout mechanism. The node stops the tip selection process if it is not able to return a response in a given time. This is controlled by the TIP_SELECTION_TIMEOUT_SEC` configuration parameter. The default timeout is 60 seconds.

There are also some breaking changes introduced by the unification of the behavior of boolean configuration flags. All boolean flags now require explicitly passing a parameter to make their behavior clearer. Also, in the past, it was possible to overwrite the values if you had passed the same value in both the configuration file and the CLI.

Many changes also happened under the hood. For example, we have made the API much easier to work with in code. This will help us whenever we are extending or making changes to our APIs. We have also improved the whole release process as we aim to shorten the release cycles in the future.

A full list of changes will be available in the release on GitHub as usual.

A shout out also goes to our community for their contributions. For example, Viossat changed the hashing algorithm for caching incoming transactions.

Another large effort in IRI is the complete rewrite of the networking layer. The code has been rewritten from the ground up, with a lot of significant changes.

Part of the process to rewrite the networking protocol was setting up the Iota Community Committee (ICC). A group of representatives voted in by the community. The members of the ICC then set up a network on which the new code is being tested.

We would like to release IRI with the new networking in the second week of July (July 8–12).

If you are operating an IRI node, then there are steps you can take in advance to be ready for the networking release.

First and foremost, the refactored IRI will drop support for the UDP protocol. That is, if you are using UDP now, please contact your neighbors and neighbor up using TCP instead.

Note:
These networking upgrades will not be backwards compatible and require node operators to update when released.

Note:
These networking upgrades will not be backwards compatible and require node operators to update when released.

There will be other changes to the configuration of the node that are worth knowing in advance. All of them will be in the documentation at the time of release, but to give you an idea:

• MAX_PEERS
• DNS_REFRESHER_ENABLED
• DNS_RESOLUTION_ENABLED

New configuration options

• NEIGHBORING_SOCKET_ADDRESS— defines the socket address to bind the TCP socket to.
• NEIGHBORING_SOCKET_PORT— 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.
• AUTO_TETHERING_ENABLED— controls auto-tethering, this was previously controlled viaTESTNETtrue, default is false (also in testnet mode).
• MAX_NEIGHBORS— rename ofMAX_PEERS, defines the max number of connected neighbors.