Opened 7 years ago
Closed 6 years ago
#1332 closed enhancement (fixed)
Implement I2CP IPC for Android apps
Reported by: | str4d | Owned by: | zzz |
---|---|---|---|
Priority: | minor | Milestone: | 0.9.14 |
Component: | apps/android | Version: | 0.9.13 |
Keywords: | Cc: | ||
Parent Tickets: | Sensitive: | no |
Description
I2P Android can listen on the standard I2CP port (localhost:7654), enabling other apps (like Bote) to connect to it. But Android does provide inter-process communication mechanisms - I2P Android already implements an AIDL interface for checking the router status. We should use AIDL (or one of the simpler provided IPC APIs built on it) to implement Android-internal I2CP.
This would use Android-specific APIs, so cannot be bundled in i2p.jar and router.jar. I2P Android will be the server-side and can include the new code directly. For client Android apps like Bote, if the new code is non-trivial (more than a single class) a better method may be to provide android-client.jar for bundling (which could be built by the I2P Android build scripts). This also assumes that new I2CP client and server types can be plugged in at will - at first glance, this is not the case.
IRC conversation:
<zzz> str4d, there must be some sort of Android thing we can use for I2CP IPC to replace sockets?
<zzz> could we do I2CP-over-intents?
<zzz> that way we could pass I2CPMessage objects between JVMs
<zzz> it would simply be a new type of ClientConnectionRunner?, which we've already extended once for in-JVM communication
<zzz> seems relatively straightforward at a 10,000 foot level
<str4d> I2CP-over-intents - no.
<str4d> I2CP-over-AIDL - maybe.
<str4d> AIDL is the Android inter-process definition language
<str4d> It allows passing "simple" data structured between processes.
<str4d> There are also Handlers, which are build on AIDL and provide a simpler way to implement sequential (first-come-first-served) inter-process messaging - maybe that could be used?
<str4d> ie. building a "raw" I2CP interface that apps can connect to.
<str4d> zzz, the more I think about it, the better your idea seems
<str4d> We already special-case the host:port combo "internal:internal" for regular JVM. We can just look for host "internal" and then switch on the port.
<str4d> Port "internal" meaning use the existing intra-process communication, "android" meaning use Android IPC
<zzz> re: I2CP, I have only a vague clue of intents and AIDL, so i guess i meant AIDL…
<zzz> FYI, "internal" is just a UI thing. For actually deciding on internal vs. external, we just look if we are in RouterContext? or not. If so, we ignore the setting and use internal
<zzz> for AIDL, we'd have to look at some details, such as is it guaranteed delivery or not, is there queueing and/or flow control in it, …
<zzz> a handler built on AIDL that has some basic queueing sounds good
<zzz> the blocking/overflow/dropping behavior may be _the_ question to answer
<zzz> brief research: our current impl queues up to 256 messages and drops on overflow
<zzz> we also have blocking writes implemented but I don't think we use them.
Subtickets
Change History (7)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
https://stackoverflow.com/questions/14973942/performance-tcp-loopback-connection-vs-unix-domain-socket
https://stackoverflow.com/questions/14625273/androidalternative-for-tcp-loopback-socket-connection-for-better-performance
https://unix.stackexchange.com/questions/91774/performance-of-unix-sockets-vs-tcp-ports
comment:3 Changed 7 years ago by
Proposed patches:
http://pastethis.i2p/show/WkSLh5IhikQuuFeb6IbQ/ i2p.i2p
http://pastethis.i2p/show/qU2HIvt5cGLvs8I84dIW/ i2p.android.base
comment:4 Changed 7 years ago by
Revised patches:
http://pastethis.i2p/show/hFyywVEeqlwmFUK2Bi6l/ i2p.i2p
http://pastethis.i2p/show/g5oKGF6n39nAiUUvzxo6/ i2p.android.base
To be tested shortly.
comment:5 Changed 7 years ago by
Above patches were used in I2P Android and Bote. I was able to successfully connect to the Bote network through I2P Android, while the regular I2CP port was disabled.
On one instance an error did occur, but I think it was because I disconnected and reconnected Bote too quickly. It has not reoccurred.
I2PSessionMuxedImpl [I2CP Reader 3] [I2P-Bote]: Disconned from the router, and not trying to reconnect I2PSocketManagerFactory [ConnectTask] Error creating session for socket manager net.i2p.client.I2PSessionException: [I2P-Bote]: Cannot connect to the router on [Domain socket connection]:0 net.i2p.client.I2PSessionException: [I2P-Bote]: Cannot connect to the router on [Domain socket connection]:0
comment:6 Changed 7 years ago by
Milestone: | 0.9.15 → 0.9.14 |
---|---|
Status: | new → testing |
Pushed:
de5c3235c69cc1575378446e22bd277d9f0064d4
i2p.i2p
7258671aa593794a76baeb3866d7de9d44fc1936
i2p.android.base
By default it will not be used; Android client apps must be using the new client library, *and* have i2cp.domainSocket=true
in their I2CP options.
comment:7 Changed 6 years ago by
Resolution: | → fixed |
---|---|
Status: | testing → closed |
Tested for many months using Bote. There are very occasional errors connecting to the LocalSocket?, but they usually disappear when trying again; any major bugs have been fixed.
I am starting an Android library in i2p.android.base to contain the I2CP client code. Android apps will pull it in as a dependency, and it will provide everything they need to use I2P in their apps (ie. equivalent to them manually bundling i2p.jar etc. in their app, but with the nice extras like internal I2CP).