Repository navigation
Supporting different delivery modes for connections #1
Description
Activity
- changed the title
[-]Better support for peer-to-peer edge connections[/-][+]Conceptual challenges for peer-to-peer edge connections[/+]on Apr 4, 2015 A major problem with option 2) is that is requires changes to the Participant code, making it impossible to use existing/foreign participants. This would limit use to systems where one has complete control over each node. And make nodes participate in multiple networks/system very difficult.
So the way forward seems to be the bindings approach.
Note that we might want to have minimal support for participants self-initializing with possibly matching queues, but this will then be secondary. Major reason for this right now is allowing use on Heroku/AMQP without needing Coordinator to set up communication...For MQTT and similar systems where the Broker cannot provide this functionality, a helper will be used by the Coordinator to perform this role. Probably hidden behind the
transport.MessageBrokerinterface.Another problem is consoliating the need for various type of communication stategies. For instance in http://github.com/jonnor/imgflo-server we want round-robin between API frontend and the workers, but the result from worker should be communicated back to the API frontend which made the processing request.
The back-comm can be done using either a reply-to/peer-based model, or pub-sub.Current thinking is to make edges be pub-sub by default (currently its transport dependent), and let a special router component implement round-robin. In AMQP (and other transports with neccesary capabilities) this would not actually be code in the coordinator, but instead just configure the broker suitably. On MQTT etc it will be implemented using a helper in the coordinator.
ACK/NACK would the be optional??All transports are now pub-sub by default. Need to still develop a
msgflo/RoundRobintype component/participantRoundRobin now exists since 1+week
Inside one role on AMQP, round-robin is the default since 2016. One can use
msgflo/PubSubpseudo-component in order for all participant of a single-role to all get the message. Example usage in imgflo-server- changed the title
[-]Conceptual challenges for peer-to-peer edge connections[/-][+]Supporting different delivery modes for connections[/+]on May 3, 2017
Right now messages will be correctly sent between Participants when they have queues/topics which are matching. Currently the msgflo Coordinator does not consider this to be an "connected" edge though...
On AMQP one can create a fanout exchange for every outport, and then set up bindings from these to the inports the outport is connected to.
Such a exchange will likely be needed for the Coordinator to be able to observe data going though the network, for debugging in Flowhub (using FBP runtime network:data messages). This because with a direct exchange, like the default, messages are only delivered to one consumer (in round-robin fashion).
Problem is that MQTT brokers does not support "binding" topics to eachother, so something else needs to perform that operation. The msgflo Coordinator could perform this, but this makes it required for normal functioning of the system (and not just debug/reprogramming).
In practical scenarios this might be a non-issue though, as the Coordinator can probably run on the same machine as the Broker.
In general there are two ways to change the connections between particpants,
complicating the architecture a bit:
From the perspective of the running system, these should be equivalent.
One could say that for participants to know where they are sending mesages is somewhat breaking the "loose binding" concept, but for MQTT that is the only possibility which does not require more than clients+broker at runtime.