Hello list, we are setting up an AMQP messaging infrastructure using Qpid (currently using proton and the dispatch router, not the broker). This is the basic set-up:
* We have a server side, with a public, known IP-address and port. * We have X number of clients going on/off the net at unpredictable times and intervals. These clients may be NAT'ed (on possible separate LANs), and might change public and local IP-address at random. * All (server and clients) are running the dispatch router locally, and connect to the server's dispatch router address on startup automatically. (The server's address is currently hard-coded in the clients' dispatch routers' configuration) We have successful in getting clients and server communicate all with each other using the server's public address/port as the only known connection point in the system. All in all, things look very promising! :-) Now we are to move on to next steps. There are especially these features we need to make sure we support: a) Sending a message _from_ a device that is not presently on-line at the moment: Devices come on/off the net at unpredictable times and intervals. However, there might be messages _from_ the device that needs to be delivered to the server when it comes on. On the application level on a client, we just want to deliver a message to the local "message handler" (i.e. the dispatch router presently), and let the application program continue working without halt. For this functionality, is it right to assume that we need to implement the broker also, locally, as this is not a dispatch router feature? b) Sending a message _to_ a device that is not present on-line at the moment: In case the device is not presently on-line, there will be no active route to it. However, it should still be addressable (aka. a "registered" device in the system), and messages for it (from any other device - server or other clients) should be delivered when it is (might be) back on-line. This relates to the previous point, but as far as we can see, for this to work, the router would need to know that the address for the device is still "legal" even though not on-line, and be able to deliver the message when it actually comes back on-line. As seen from the application program, the situation is the same as the previous point. Is it right to assume that we broker for this? c) Time to live on messages: Every message should have a time-to-live parameter. I.e., if the message is not delivered before ttl is expired (ref above cases), the message can be discarded at the local "message handler" level. Is this AMQP/Qpid functionality; which components do we need to support it? d) Resuming large messages: The payload of messages could be up to (in really worst cases) several gigabytes. Is there AMQP/Qpid functionality at some level that makes the transfer resume (rather than restart) in case the is a network dropout during transfer? Where does this functionality exist? Broker/router/messager lib...? Can the qpid broker replace all dispatch router functionality in these cases, or is it an addition to the dispatch router functionality? Any pointers or comments to the above is highly appreciated. And as for RTFM, yes, we do...! But some times, the information is not readily available, and we want to speed up the process of learning this... :-) (Naming of features above might not be in line with official AMQL/Qpid terminology....) Best regards, Tor Rune Skoglund [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
