First off, I assume this is mostly a reaction to the recent downtime we've had with the API server. Those issues should (hopefully) be behind us, and honestly I'd rather we get to a point where you just "know" that the API server will be up rather than needing a check like this. Obviously that hasn't been the case recently, though :-)
With that said, it's not a bad idea, so if you want to do it, go for it. However:
The Aaron said:Ken L. said:
I'm not aware of the complete topology, but I assumed that the API server sent updates to each client connected to a campaign. For something that updates n times a second for m connected clients is n*m updates sent per second by the server. That alone isnt enough, but throw in a bunch of other things on that one sandbox, then the number of campaigns running and.. well the result is it may get bogged down trying to serve all those requests.
Really depends on the network model used, queuing system used (simultaneous detection for packet compression etc..). I'm not a network engineer, but given the profession we all dabble in many things.
Sure. I'm just saying this is no different than say, setting the hit points on a token. Could change it to be reaction based instead of on an interval. Maybe have it change to a random bright color different than current whenever a token changed... options. =D
I think it's probably overkill to have something update every 200ms to tell you the API is still up. If the API goes down, you don't need to know *that* quickly. Honestly, I think just having a "!apiup" command that responds with a whisper is probably sufficient. If you do want something that is going to constantly tell you the API is running, I would back it off quite a bit. 1 second tops, 5 seconds is probably more what I would choose, but again I'm not going to say you can't do it or anything.
I'm also not a fan of the idea that a single campaign would be sending that info to several player objects redundantly, though...why not just make it so it sends to the player who most recently requested it? In addition, it wouldn't be a bad idea to only send the request to online players so you're not changing the color values of players that aren't even being displayed.
The API server would need to send 1 "request" to our real-time shard for each color change (since each thing is happening to a separate object), and then the shard will process (make sure it's valid, store the new value in the database, etc.) that request and send it along to each client. This is a pretty small amount of data so it's not going to be hugely taxing. Then again, if everyone puts it in every campaign it could add up? So who knows.
I think the thing that I would be worried about is over-saturating my own sandbox. We've gotten really good at isolating sandboxes so that they can't use up the resources of the whole API server...you have a limited amount of CPU, memory, and network to work with. Do you want something important like an update to a token for gameplay or a roll from an API command getting slowed down because every 200ms the sandbox is sending 5 requests to change player colors? That would be my biggest concern if I were a GM about using scripts like these that update data constantly.
