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
trs [ at ] swi.no
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
trs [ at ] swi.no