Any thoughts for wrapping a Swarm in an actix Actor?

[raptros]

After some time of looking at various examples - especially the file sharing example - it struck me that for my own efforts, it'd be really convenient if I could wrap the swarm in an actix Actor type, since actors provide a convenient mechanism for associating request and response types (handling, for example, all the request and response channel stuff).

After playing around with it a bit, though, I am not sure it is possible - the relevant add_stream method - https://docs.rs/actix/0.13.0/actix/trait.AsyncContext.html#method.add_stream - wants the Stream to have 'static lifetime, which I don't know how to achieve, especially given that I want the struct implementing the actor trait to also be able to interact with the swarm directly (e.g. so that handle calls can interact with the swarm to implement commands from other places). It's possible though that I'm missing something.

Does anyone have any suggestions?

[elenaf9]

Hi @raptros,
In a project that I used to work on we implemented an actix actor that managed our libp2p swarm.
However, we implemented the the Actor trait on top of an interface similar to the Client in the file-sharing example, instead of integrating that logic in the actor implementation itself. So an additional background task was still needed.

Like it is done in the file-sharing example, we polled the swarm in an event-loop in a background task. To execute commands on the swarm we had a mpsc channel to the event-loop. In your case, you could simply forward messages (that your actor receives) through this channel to the background task.

Additionally, the event-loop got passed an mpsc::Sender on init. This was used to forward relevant swarm events (and e.g. incoming requests). And since that channel is 'static, this was what we used in Actix AsyncContext::add_stream: https://github.com/iotaledger/stronghold.rs/blob/451bcc2cd0828cada01e55def719b532252a337a/client/src/actors/p2p.rs#L135-L162.

I don't think there is a way to add the swarm itself as stream if you also want direct access. But maybe this still helps.

Edit: I guess you could at least save the additional background task by implementing Stream directly on the event-loop and return events there instead of sending them through the mpsc channel.

[raptros]

That approach is one I've been contemplating, as the fallback approach to the issue. Thanks for the reference and the code link, it looks like there's some useful techniques in there for making handling and responses work more conveniently, so I'll have to dig into it.

That said, there's definitely a part of me that's still dissatisfied with the idea, since it seems to me that an event loop that polls various sources and can send back responses is exactly what an actor is in the first place, so it seems frustrating to not be able to just wrap the Swarm up in the already-implemented abstraction. Would the rust-libp2p group be interested in maybe exploring how to enable that in the future? I think it'd be an interesting line of development.

[thomaseizinger]

It might be worth checking out xtra: https://github.com/Restioson/xtra

It is an actor framework that was originally actix inspired but has evolved massively since then. The next release is around the corner and includes massive clean-ups in the API, including the possibility to write your own event loop which allows you to poll the swarm together with the actor's mailbox.

See https://github.com/Restioson/xtra/blob/master/xtra/examples/custom_event_loop.rs.

[raptros]

Interesting, I'll give it a try, thank you.