Situation description: Let's say we have a central server with a queue for every connected node. Every node also has its own exchange and queues. Each of the server's queues is 'routed' to the node's exchange, which delivers "automagically" to local (incoming message) queue(s) based on message type/topic/whatever. The node's applications then reads from its right node queue.
There is only one "physical connection" to a single SERVERIP:PORT, initiated from each node. The nodes might be on different types of networks with different characteristics for latency, bandwidth, etc. E.g. could we have cabled gigabit nodes and GPRS mobile nodes. It is our current understanding that a simple queue delivers one message at a time. This means that a message in transfer will block queued messages that might be more important until the message is fully transferred - which might take some time on low bandwidth, unstable networks. So how do we make sure more important messages gets priority? First idea was to use the priority queue. Even if the queue will send the higher prioritized messages first, they will still block other messages while being transferred. Not good. Next idea: Use a queue for each priority level of messages to each client. Still, if there is just one message at a time "on the wire", we have a problem, unless one in some way can "multiplex" messages from different queues. Which means that lower priority messages still will flow through the connection, albeit slower (which is OK) when higher prioritized messages are also being delivered. Are our naïve assumptions above correct? Or are we imagining a problem that there is already a standard solution for? How would you suggest we setup our system to handle prioritized messages without blocking any of them, but sharing bandwidth "fairly" based on a message's priority? How about control messages while payloads are being delivered? Are they blocked until messages is delivered, or will they get through in some way? - Tor Rune Skoglund, learning... --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
