Check if I2P router is running

[chimp1984]

To start and stop an I2P router requires some time and it is harmful for the network to run a router only short-term or shut it down in a non-graceful way.

We are starting the integrated I2P router when Bisq starts. This can take a few (5?) minutes until its available. The process is started from the Bisq process, so the I2P router process will get terminated once the parent process gets terminated.

We should check before starting I2P router if there is already a router running on the system (either an externally started I2P router started from the I2P console or our internally integrated one running in a process started by Bisq). If one is running we do not start the router. At shutdown we should leave the I2P router running in case we started it. We can add a user-setting for disabling that, so that I2P router gets also shut down with Bisq. If user choose that option we should show them info that this is not recommended behaviour. It would be good to add a graceful shutdown in that case.

[c4talys7]

I volunteer for this task.

[zlatinb]

Hi,

Embedding the java I2P router is by far the easiest way to get I2P going with Bisq. Sure, an external router is possible as well, but managing that process from Java is in my experience quite tricky.

Regarding the concern that it takes too long to launch, I recommend you try the latest router 1.8.0 (available on MavenCentral) where the initial tunnel building time was shortened significantly. Also as I pointed out to @c4talys7 there is an unnecessary sleep(5000) when the router is launched; that can safely be replaced with a fine-grained sleep loop.

As far as nodes leaving too quickly - by default java i2p routers will not relay data on behalf of others for the first 10 minutes of their uptime. There is virtually no harm to the network if a node comes online and then goes offline in the first ten minutes. That interval is configurable.

If you use only the abstractions provided by the "I2CP" protocol it doesn't matter if the router is embedded, external, on a different host or running the C++ implementation I2Pd.

[zlatinb]

Another thing that came to my mind is logging. I see you use slf4j annotations and while I've never used those I can sort of guess how they work. The I2p router however uses a homegrown logging system which you will most probably want to override and redirect to slf4j.

Take a look at this package for a redirection layer to JUL logging. You need to call router.getContext().setLogManager(customLogManager) after creating the Router object but before calling runRouter(). See the javadoc for that method for more info.

[zlatinb]

Another tricky part of bundling a router ais the proper inclusion of the jbigi native libs, the geoip database and the various blocklist files. I2p will function fine during development without those but for a production distributable you definitely want them.

Unfortunately the cleanest method I could think of doing that was to check out the i2p source tree, build it with ant for the respective platform and then copy those files from the staging directory. That approach does not lend itself to automation so if you can think of a better way it would be great.

[chimp1984]

Another tricky part of bundling a router ais the proper inclusion of the jbigi native libs, the geoip database and the various blocklist files. I2p will function fine during development without those but for a production distributable you definitely want them.

Unfortunately the cleanest method I could think of doing that was to check out the i2p source tree, build it with ant for the respective platform and then copy those files from the staging directory. That approach does not lend itself to automation so if you can think of a better way it would be great.

The files can be included as resources, no. The native libs are more ticky. Would be cool to have them separates as libs so only those need to be built platform specific, and they usually change not, so its a one time build. Do you think that could work?

Re production: Beside the performance gains is there any other difference?

[chimp1984]

@zlatinb Another question. As far I understand if you run 2 I2P routers (e.g. when testing 2 clients) I2P recognizes its on the same host and does not route through the internet, thus local testing gets more tricky as its not the real behaviour. Beside isolating the clients in VMs do you know of another way to enforce that I2P does not do those shortcuts? Maybe there are some dev options...

[zlatinb]

Re native libs: yes performance gains are the main benefit they provide specifically the modpow fuction for big integers. And yes you can include the libraries in the source tree and package them into a jar at build time. That is what the ant build of the i2p router does.

Re multiple routers - you can run multiple routers onthe same host, but not in the same jvm. Just make sure the home and settings directories of the routers are different as well as all the ports that the routers will open.

[c4talys7]

Howdy @zlatinb, some thoughts on your comments bellow:

Another thing that came to my mind is logging. I see you use slf4j annotations and while I've never used those I can sort of guess how they work. The I2p router however uses a homegrown logging system which you will most probably want to override and redirect to slf4j.

Take a look at this package for a redirection layer to JUL logging. You need to call router.getContext().setLogManager(customLogManager) after creating the Router object but before calling runRouter(). See the javadoc for that method for more info.

Thanks for the pointer Zlatin, I also did check the docs and it's mentioned in there as well, so this is something I started implementing whenever the embedded router is being used.

Another tricky part of bundling a router ais the proper inclusion of the jbigi native libs, the geoip database and the various blocklist files. I2p will function fine during development without those but for a production distributable you definitely want them.

Unfortunately the cleanest method I could think of doing that was to check out the i2p source tree, build it with ant for the respective platform and then copy those files from the staging directory. That approach does not lend itself to automation so if you can think of a better way it would be great.

Here my initial line of thought was, create a fork of the I2P repo and change slightly the ant build scripts to generate those files. Thoughts on this?

There were some other changes I've already made, including the ability to use an external I2P router that was previously installed by the user. I'm testing some of these developements, but not stable enough to consider complete.

Regards,

c4talys7

[zlatinb]

Here my initial line of thought was, create a fork of the I2P repo and change slightly the ant build scripts to generate those files. Thoughts on this?

That would work, there are probably ant targets that do what you need already. It really depends on how your general CI/build system is structured.