4 ms·
Soft real time data. Anything that would be out of date by the time you had timed out and resent. For example a packet of range data from a robot. Drop one? Wor
by robotresearcher 12y ago
Soft real time data. Anything that would be out of date by the time you had timed out and resent. For example a packet of range data from a robot. Drop one? Worthless now, but another one will be along in 50 msec or so.
- laichzeit0 12y agoWhy would you use a queue instead of a topic for a use-case like this?
- robotresearcher 12y agoFrom the point of view each of the subscribers to a topic, they see a queue.
- politician 12y agoTelemetry from an external data source wouldn't be delivered from a queue, it'd be published into a queue. Think IoT into an AWS Lambda instance -- you've already paid the micro-cents to handle the request, so why not just forward it into Kinesis? (How does putting that data into a lossy queue save you time/money/effort?) EDIT: Misread your example. The idea is that the robot has an outgoing buffer containing time-series data that it tries to publish on a best-effort basis? In that example, it seems like a ring buffer would be a better solution than a messaging system.
- robotresearcher 12y agoA ring buffer of length one minimizes latency.
- angersock 12y agoAnother example of this sort of behavior was the netcode common to Quake and many other shooters--since lots of history is sent as full state instead of deltas, it's "okay" to have lost packets. It's not ideal, and it'll screw up certain types of things that really, really want a contiguous history of events, but for normal play it's perfectly fine. When doing client-side prediction, then it may become useful to have historical data, but as my sibling post suggests, a ring buffer of length one minimizes latency. It actually might be interesting to see a writeup on multiplayer games viewed through the lens of eventually-consistent distributed databases.