Daemon as shared library.

[cheatfate]

In most of the cases daemon usage is fine, but sometimes your project could not spawn actual daemon executable. Is it possible to wrap the daemon inside of simple shared library, this library can export for example just two functions start(configuration) and stop().

So when application loads shared library and calls to start(configuration) daemon's main() function will be executed in new thread (or in any other possible ways). In such case all the named sockets created will be inside of application, so it can be possible to use daemon in iOS (for example).

This is of course not priority issue, but it would be very handy to have such feature.

[raulk]

So the idea would be to compile the daemon down to a shared library. This wouldn't be too efficient, because to my knowledge, the library will embed the Go runtime. Anybody knows if this would be possible with little effort?

Browsing -build-mode=c-shared examples, they look pretty flat and only import stdlib. Uncertain what the result would look like with the dependency tree we have.

Would it be so simple as keeping everything as-is, and creating exported entrypoints functions as suggested in the description?

[raulk]

@bigs @vyzo @Stebalien – any clue here?

[Stebalien]

Yeah, this actually looks like it might work.

[bigs]

yep. as long as the exported interface is very simple (like the start/stop) i think it should work

[Stebalien]

I assume we'd expose the API, right? That is, start, stop, newstream (returns a handle), close, read, write, reset, etc...

[cheatfate]

@Stebalien, nope, the only API exposed is start(config) and stop.
start(config) starts opens control socket and start serving on like it currently does.
stop() stops all processing.
All other APIs are available through control socket.

[vyzo]

This sounds like a very reasonable. We should be able to export Start/Stop functions for embedding in the application.

[jrhea]

I like the idea of packaging this as an .so and have an immediate need for it. I am going to see if I have time to prove this idea out this week.

[bigs]

thanks! happy to review once it’s up. cole

…

On Nov 20, 2018, 11:51 AM -0500, Jonny Rhea ***@***.***>, wrote: I like the idea of packaging this as an .so and have an immediate need for it. I am going to see if I have time to prove this idea out this week. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[jrhea]

@bigs @vyzo @raulk

tldr;
i was able to run the daemon from Java. do u mind providing some guidance (or an easy button) on how to test the daemon?

i created a .so and exported a start() and stop() to Java via C and JNI. I made a sample Java app to prove that I could run the daemon from Java. This is the output I get after calling start() from Java:

$ java p2pd
Control socket: /tmp/p2pd.sock
Peer ID: QmQXh4GVy1EYv79nfJEdkkzF8o6877UTqqg3eZHRyrvDpP
Peer Addrs:
/p2p-circuit
/ip4/127.0.0.1/tcp/64150
/ip4/192.168.1.129/tcp/64150
/ip6/::1/tcp/64151

Thanks,
Jonny

[vyzo]

There are some example programs you can use as a starting point for testing in gerbil-libp2p/example.
There is also the go client which has a bunch of tests.

[bitnom]

Re-opening as reference and possible request for comment for same Nim repo issue: vacp2p/nim-libp2p#21

[aschmahmann]

Is this still a requested feature? It seems to me like a large amount of the functionality could be achieved by using go-libp2p as a shared library and not the daemon itself, or by just running the daemon and then writing a client api for a target language.

Feel free to reopen if this is still a requested feature.