Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Blocker] No External Networks Connection Verbs #34

Open
biscuitWizard opened this issue Feb 4, 2024 · 4 comments
Open

[Blocker] No External Networks Connection Verbs #34

biscuitWizard opened this issue Feb 4, 2024 · 4 comments

Comments

@biscuitWizard
Copy link

Many games, and maybe all of them, require the ability to have verbs that open TCP sockets as listeners or to establish outgoing network connections at the verb level.

I understand this is contrary to your vision but it will present a significant if not insurmountable barrier of entry in limiting adoption of your server.

Games like Torchship use sockets to talk to external simulation layer services like our login server which uses TCP and not REST to communicate. Similarly, our space simulation server which is written in Rust also uses TCP to communicate with the game over a custom messaging protocol I wrote for that specific implementation. Which would be unideal to move to the server layer because it's iterated on so frequently it would result in significant service downtimes or stability issues during testing, which verbs offer in safety on the VM.

Other games use those connections to talk to things like mail forwarding agents.

@rdaum
Copy link
Owner

rdaum commented Feb 7, 2024

Without getting into the weeds of your specific case ... I think the right thing to do is to perform that communication inside the moor runtime itself in Rust code. The way that would likely work is via zeromq to/from the daemon, similar to how the inbound network stuff happens.

None of this is of course documented yet, but the daemon exposes RPC facilities over 0mq to do things like invoke a verb, subscribe to the result of a verb invocation, etc. And there's nothing stopping me from adding things going the other way -- having builtins etc in MOO which can call out over 0mq to other services running on the host.

The LambdaMOO networking model is kinda bad, and I don't want to inherit it. It's tied to the oddities of the LambdaMOO network listen loop, for one. And it's got somewhat awkward semantics.

But more than that I do not want verbs in moor being tied to particular network protocols. The daemon itself only speaks to the (inbound) network activity through RPC calls at this point, which means that web, "telnet" (tcp), console etc sockets are all equal "participants".

@biscuitWizard
Copy link
Author

I hear you, but it would be more attractive for moor to be able to drop in to existing environments as stated with the project's goals of backwards compatibility. In my case, I couldn't even log into my game to test moor because my login server .. is another service outside of the game communicated with over an outgoing TCP socket connection that's established from the game to the service.

Most games don't do that, or any, I think. So that's definitely a me problem, but there are definitely plenty of games that contain usages of that verb.

@rdaum
Copy link
Owner

rdaum commented Nov 24, 2024

Moor now supports listen()

Opening outbound network connections may come.

@biscuitWizard
Copy link
Author

Fantastic news!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants