Add universe-style networking to reactors

[dbp]

I was talking to @blerner about this the other day, and after that, looked up a bit of what it would take.

It seems like WebRTC is mature enough (supported in most browsers for a while) to probably be able to support the types of patterns that a port of universe (https://docs.racket-lang.org/teachpack/2htdpuniverse.html) would need -- in particular, being able to send peer-to-peer messages, whether the peers are in the same window or remote across the network. e.g., if built upon this library: https://peerjs.com/ (as the core APIs are... complicated), the centralized server (CPO) would be responsible only for connecting clients, not relaying any data.

There probably would need to be a bit of thought put into the actual exposed API for identifying who you want to connect to (for privacy, usability, etc), but at the bare minimum, it seems possible. And, of course it may be worth revisiting the actual server / client API design rather than just replicating.

(WebRTC is, of course, intended for stuff like voice and video, but the API allows plain data messages too).

[shriram]

Thanks, Daniel. The question is, is there an audience for it? I don't use Universe. I'm not sure who would actually use it, which makes the development but even more so maintenance effort perhaps questionable?

[dbp]

Perhaps not.

But, I'm not sure about other schools that use HtDP, but at least at Northeastern, Universe is usually a core part of course projects (i.e., consumes several weeks of homework assignments, spread across middle to latter part of semester), and I hear rumors every so often about a hypothetical HtDP->Pyret pathway (perhaps not here, but some places), so...

[shriram]

We've talked, very airily and loosely in the past, about how HtDP 3/e might have code in both Racket and Pyret. But it's not particularly in the offing. Not to disregard your suggestion — it's neat that the Web tech is finally in a place where we can do this with standard components, etc. But for right now, I think our cycles are best spent on making the support for DCIC really good.

[dbp]

No offense taken -- I left this here partly because I searched for an issue on the topic and didn't see any mention of it, so thought it was worth writing down -- not because I particularly thought anyone would work on it right now!

(Risking thread drift -- best way for feedback on DCIC? I created an issue on a repo you have, but it was the first one, so I worry that's not the right venue!)

[shriram]

Yes, I think it's great that this is here, because anyone searching on this topic can find this discussion in the future. (And a sufficiently ambitious person can even implement it for us. <-;) For DCIC, I did get your repo request, and that sounds like a great way to go. I've put it on my winter break stack. Thanks!

[stchang]

Coincidentally, I just was thinking about this exact idea, but for Racketscript (which has its own basic big-bang implementation).

But I was looking at websockets instead. Wouldnt that be closer to the client-server 2htdp/universe model?

[dbp]

So, websockets should work (it's what I was looking at first), but it's not peer to peer, so at least in the CPO / Pyret world (i.e., hosted online IDE), students wouldn't be able to implement the "server" parts unless there was a server that was relaying all traffic (which sounds... possibly expensive -- perhaps fine for a single class, but harder when you are running the infrastructure for an arbitrary number of classes). If, instead, there was a fixed server running somewhere that you just connected to (and students only implemented the client), it should work fine (Websockets don't have same origin restrictions, I believe).

[stchang]

Yes, they wouldnt be able to implement the server part in the browser. But if one really wants to teach the client-server model I'm not sure there's a way around it, since that's sort of the definition of a server?

But a peer-to-peer browser-only variation of universe is definitely a great idea, and would make a nice student project, so I might borrow this idea if that's ok :)

(btw I didnt know about peerjs so thanks for that pointer)

[dbp]

Of course!

Yeah, part of the reason why I thought it might make sense to use WebRTC is that even if you don't want students to implement the server, it's nice to be able to have test servers (i.e., launch-many-worlds) that run "locally" -- and locally to a web IDE means in the browser. So while the APIs might still make a distinction between clients and servers (as 2htdp/universe does), the underlying networking would allow both to be implemented in the browser.

[jpolitz]

So I'm working with @anzook on an integration of code.pyret.org into Virtual Math Teams (https://vmt.mathematicalthinking.org/).

The idea is that they manage a bunch of state + social stuff around iframed tools like Desmos or Pyret.

They have a peer-connected setup with a notion of an “in-control” user and and “viewers,” where viewers can take control of editing, and edit events are passed around and synchronized. (This is simpler than Google Docs, because edits only come from one user at once).

I bring this up because the infrastructure sounds like what would be needed for peers to pick a “server,” share communication, and so on. It's not at all our current goal, which is shared editing in a classroom setting, but the infrastructure is there...

[dbp]

Oh, also -- just a random thought -- one troublesome part about universe programs is server state. I think often people work around this by having the server not keep any state (just act as a message router), but there are nice applications where the server does have state (e.g., we had students build a minecraft clone that started server-less and then we added a server that had all students in one big world which had 10 x 10 of their grids -- and when they walked off the edge of one, the server would hand them the next).

The problem is students writing implementations that don't follow the protocol and then tests that match their non-conformant protocol. Everything works until they connect to the server and then things are confusingly wrong. Obviously this is a problem in general, but this particular context seemed to be particularly frustrating.

Matthias said that, to deal with this in the past, people had shipped executables to test against, but that's somewhat heavyweight, and this seems like a place where Examplar could be quite useful (which, in the same way ships compiled implementations to test against, though in a more robust way).

[shriram]

Indeed, in situations with a predictable game, I think Examplar could be super-useful as a "counterparty" (whether the game is distributed or not). And it would also showcase the World/Universe model in that it's designed for testability.