cl-gserver
cl-gserver copied to clipboard
mdbergmann
Implement remoting
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>
Gota think about this. Interesting topic, in particular as I never really worked with networking code in CL.
you can choose a data store format to transfer data between networks, such as cl-store.
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.
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.
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.
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.
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.