-
Notifications
You must be signed in to change notification settings - Fork 1
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
Emulator <-> API connection requires 4 API calls per frame. #17
Comments
New idea for reducing this bottleneck:
This stops the API being restful but will reduce latency and network traffic. |
That could definitely work - for now, I'm looking into running the constant polling in a separate thread, with controller still being stored in shared memory (and just being written). The bottleneck was because of the blocking nature, so that might help in the short term. But definitely switching to either UDP/using Kafka (and polling at 60 Hz as per Nyquist theorem might be suitable) |
See #20 for the multithreaded approach. Still working on testing it (need to sort out my linux again). As part of the new Java server (#19), looking at making it fairly decoupled so we can accept user requests from REST, while throwing state outputs to either REST/UDP/TCP or even Apache Kafka (which might be useful if we want to have it dealing with multiple games in the future). If you want to start looking into the UDP based method that'll be good, as I think that'll be the best solution for now (Kafka is definitely a pipedream at the moment) |
Do kafka streams support non Java consumers? The Plugin won't necessarily like the data fed to it? |
Yes, just depends on the serialiser/deserialiser: we would need to use a Json Serialise/Deserialisation based scheme, rather than bytes directly. But there is a C API for Kafka. UDP for now might be the best shout, since we only have one session, providing we fix the hostname based issue (so we could host the central server somewhere other than locally) |
This is a slight bottleneck, as the emulator input plugin blocks while the TCP socket fetches the response, causing stuttering.
Instead of requesting 4 responses per image frame, instead request 1 response containing the entire memory buffer.
This will require a slight change in the JSON structure, such that:
We can then parse this more easily, using only function calls on a string instead of blocking the input thread.
The text was updated successfully, but these errors were encountered: