search

mdbergmann / cl-gserver

Sento - Actor framework featuring actors and agents for easy access to state and asynchronous operations.
https://mdbergmann.github.io/cl-gserver/index.html
Apache License 2.0
195 stars 15 forks source link

Implement remoting #19

Open mdbergmann opened 3 years ago

mdbergmann commented 3 years ago

Remoting in the sense of having actor systems on different hosts where sending messages is location transparent. Meaning actor A in system A can send and receive message to/from actor B in system B.

The path of the actor thus has to be extended to specify an URI, like: clg://<host>/<actor-system-name>/<actor-path>

mdbergmann commented 2 years ago

Gota think about this. Interesting topic, in particular as I never really worked with networking code in CL.

rail4you commented 2 years ago

you can choose a data store format to transfer data between networks, such as cl-store.

wmealing commented 11 months ago

The kind of "simple" way erlang does it might be the easiest, a network facing deserializer that ends up pushing it into the target pid triple. Looking forward to seeing how you attack this.

mdbergmann commented 8 months ago

I should finally tackle this. Got some ideas and did some experiments with usocket. Wondering though if WebSockets would be a better approach even though they come with more dependencies, like Hunchentoot.

nyx-land commented 8 months ago

Why were you thinking about using websockets instead of just TCP/UDP? Also, not sure if you've seen it before, but there's already a system for distributed parallel computing using lparallel (https://github.com/lmj/lfarm), although it hasn't been updated in a really long time. Might be able to build off the work already done there.

mdbergmann commented 8 months ago

Yeah, I've seen lfarm. It's not so much about parallel computing, but to create remote actor networks seamlessly as if they were local. Location transparent. WebSocket traffic has some advantages is regards to reverse-proxies, network load-balancers and that sort of thing because it's easier to identify the type of packet. It might also be easier to apply a security on top of it. Zero trust networks and so on.

nyx-land commented 8 months ago

My two cents as a complete rando, from having had to add a patch to websocket-driver to have the client not crash my entire computer from opening tons of threads and maxing out the CPU, is that the websocket situation for CL isn't great right now on the client side at least. Presumably something like this would need both the client and server parts and I imagine it would be a real pain to try to get something as complicated as a networked actor system working reliably with it. But it could also perhaps be a good stress test for the websocket-driver client implementation (which is I think currently the only one that exists for CL), or just an excuse to implement an entirely new one. I'd looked into trying to do that but reading RFCs makes my eyes glaze over.