Join GitHub today
shared object - ref impl with java/jni #28
Functionalityi can fire up two daemons on two different domain sockets:
The first one is run from java
$ java p2pd Control socket: /tmp/p2pd.sock Peer ID: Qmb3mEWb7JGBxzduizmFnzQ14uYaqsFqmsCU4tssMRY3rT Peer Addrs: /ip6/::1/tcp/61459 /p2p-circuit /ip4/127.0.0.1/tcp/61458 /ip4/192.168.1.129/tcp/61458 /ip4/192.168.2.65/tcp/61458
the second one from go:
$ p2pd --sock=/tmp/p2pd2.sock Control socket: /tmp/p2pd2.sock Peer ID: Qmbr1NfbBMAzhWTxsJUYu1oXXHhSVRx9BW13qR8uMXuhio Peer Addrs: /ip6/::1/tcp/59344 /p2p-circuit /ip4/127.0.0.1/tcp/59343 /ip4/192.168.1.129/tcp/59343 /ip4/192.168.2.65/tcp/59343
Then I can run two clients to interact with each daemon respectively:
client 1 - listen for message
$ java p2pc --command=ListenForMessage
client 2 - connect to other daemon then send message
p2pc --command=Connect --pathc=/tmp/p2c2.sock --pathd=/tmp/p2pd2.sock Qmb3mEWb7JGBxzduizmFnzQ14uYaqsFqmsCU4tssMRY3rT /ip4/127.0.0.1/tcp/61458 p2pc --command=SendMessage --pathc=/tmp/p2c2.sock --pathd=/tmp/p2pd2.sock Qmb3mEWb7JGBxzduizmFnzQ14uYaqsFqmsCU4tssMRY3rT FOOOOOBAAAAAAARR
i am leaning towards packaging
into a Java API that exposes all the functionality needed to implement the beacon chain. this would save me the trouble of implementing all the p2pclient code in Java. this pattern might be useful for other beacon chain implementations that don't have libp2p implemented in their project's language.
If you type
Please take a look and let me know what you think.
The code only supports these commands:
I was holding off on implementing more functionality until you guys OK this mode of operation. That highlights one negative aspect of this mode...going forward there will potentially be one more touch point when functionality is added to the daemon. We will need to make sure it is made available to the shared object. That being said, the other option would be to create a "LibP2P Client Library" where this is housed. Thoughts?
Hey @jrhea – FINALLY I had time to review this in-depth! Thank you so much for spearheading this effort in the community
Being only vaguely familiar with Cgo, I would've expected the native interface to mimic the client's public interface. In my head, the design would look like this:
How does that sound, @jrhea? Happy to collaborate to push this forward.
@raulk Thanks for the reply!
All good my man. I was happy to do it. I appreciate you guys letting me participate.
Totally agree and that is exactly what I would like to discuss on our call. I just implemented the startClient piece with 'magic strings' as commands to prove it works. When I started the PR I could see that the daemon was still early in development and I didn't want to waste too much time nailing down an interface until you guys were ready. I figured that once you guys were ready, we could all agree on what this interface would look like.
Cool. I think that structs are the only type that might be a problem (unless they are defined in C), but I think we can work around this issue.
Yes, exactly. That is probably the key thing to work out. The Java or C# side could either poll for a message received that matches the stream id or it might be cool to just call an externally defined method from Go like ext_stream_rvcd(int id) - sort of like a callback - and that could avoid polling.
I like your brain. I think we are on the same page! I really think there is tremendous value in creating a rich interface to other languages so that must of the heavy lifting is done on the Go side. That being said, some teams (e.g. @mhchia ) have already picked the IPC endpoint as their integration point. That is fine though. That is why I had the Makefile create two versions of the shared library:
@jrhea yesterday I updated the target branch for this PR to the
Notes from the call
We see this moving forward as a set of discrete PRs:
We discussed concurrency models, i.e. how to expose native API methods whose Go client counterparts deal with channels. Callbacks and event loops were two suggested models. @jrhea to open issue to discuss.
Instead of creating one glue/translation layer (.so lib) between native API <=> Go client, we can create one per each concurrency model we want to support.
Anything else you guys want to add?