Gordon, thanks a lot! This was the kind of "missing link" information I needed. :-D
I could suggest that this info should be added to the web page, with some "Understanding the basics" or "Dummies intro" heading or something. I am sure a lot of new users would appreciate this. Best regards, Tor Rune Skoglund, [email protected] Den 15. jan. 2014 14:00, skrev Gordon Sim: > On 01/10/2014 06:07 PM, Tor Rune Skoglund wrote: >> So what do I need to get started? Proton only, or Proton + a broker like >> the C++ one? Or just Proton? Is the Dispatch Router optional? It is >> "built on Proton" ? Does it "include" Proton then? Is there any point in >> having the router and a broker? Whatwhatwhat? :) >> >> My point is, it would help if there were some kind of "Dummies guide" or >> "Getting Started" link on the web page. For those of us that have not >> done much practical work with of "queues", "brokers", "routers", >> "whatevers", the terminology makes little sense and getting along with >> the first steps are a little bit frustrating. >> >> Basically, I want to deliver messages with some kind payload, from A to >> B, or B to A - or even from A to all Bs - reliably, quickly, and some >> kind of automagic resume in case there is a network outage during the >> delivery, and a yummy API for my application (in C++ or PHP). >> >> Where to go next? > > Very fair point! Thanks for the feedback and the list of questions. > I've tried to take a quick sweep at answering them to see if this is > the sort of information you would like to see and to get further > feedback on gaps or things that are still not clear. > > Proton is a library to help things that want to speak AMQP 1.0. > > At present its really two distinct APIs. One is entirely independent > of any IO approach, it is just a protocol engine that takes bytes in > and give bytes out without caring where those bytes came from. The > other is a more complete solution that handles connecting, reading & > writing sockets etc, this is called the 'Messenger API'. > > Some AMQP 1.0 enabled components within Qpid use the proton engine for > this support (qpid::messaging, c++ broker, dispatch router etc). > > The messenger API allows processes to communicate without any > intermediary. It can also be used to communicate through an > intermediary such as the c++ or java brokers or the dispatch router. > Whether you need/want an intermediary depends on how complicated the > communication patterns are (and how many different processes need to > communicate). > > Intermediaries work by having both the sending process and the > receiving process connecting to the intermediary, and relaying or > forwarding the messages from the sender to the receiver. This prevents > either sender or receiver having to accept incoming connections, or > even from knowing where the other party is located. > > The store-and-forward pattern offered by some intermediaries allows > the producer to send a message for eventual delivery to the receiver > even if the receiver is not connected at the time of sending. This > pattern is the common one for traditional message brokers. These use > message queues in which to store messages until they can be delivered > to the/an intended receiver. > > Intermediaries can also relay or forward the message from one sender > to many receivers. This saves the sender from having to connect to all > the receivers itself. This is the 'pub-sub' pattern. The pub-sub and > store-and-forward patterns can be used together. > > Reliable message delivery works by having receivers confirm that they > received messages. Until confirmed by a receiver, sent messages are > considered 'in doubt'. If a failure occurs, in doubt messages can be > resent. This gives an 'at-least-once' delivery guarantee. Assuming the > failure is transient in nature, messages will be delivered to the > receiver, but they may be delivered more than once. (This happens when > the receiver did get a message, but where the sender did not receive > the confirmation before the failure). > > The stronger, exactly-once delivery guarantee requires some mechanism > to detect and eliminate duplicates. > > Traditionally, most brokers will confirm receipt of a message to the > sending application independently of delivering that message to a > receiver or getting confirmation that the receiver actually received > it. This is again the store-and-forward pattern. > > A key distinction between brokers and the dispatch router is that the > latter doesn't offer store-and-forward. It will route the messages it > receives to the applications they are intended for and can support the > pub-sub pattern, but if there is no receiver it won't generally hold > on to the message on the senders behalf. Reliability guarantees with > the router are end-to-end, i.e. when the receiver(s) confirm receipt, > that confirmation is passed back to the original sender. Brokers will > also tend to have some more advanced/specialised features such as > transactions, last-value-queues, prioritised delivery, durability, > message selectors etc. > > Dispatch router is an intermediary designed from the start to be > distributed. A network of dispatch routers can handle redundant paths, > which provides a useful tool in building resilient communication > channels. > > Brokers can be connected to the dispatch router network also, e.g. to > provide some store-and-forwarding guarantees where needed, or as a way > of getting specialised broker behaviour. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
