[zeromq-dev] source material for TIBCO to ØMQ migration

[Scott]

Has there been much historical discussion about UNRELIABLE multicast
PUB/SUB? We certainly have applications that just use OSC/UDP
multicast, since it's better for the application to get the latest
data if it didn't get a previous message; but I'd rather migrate
everything to zmq!

On Mon, Jan 3, 2011 at 5:15 AM, Steven McCoy <steven.mccoy at miru.hk> wrote:
> I'm working through messaging pattern examples for TIB (MSA), Rendezvous 5,
> TIB/Rendezvous 6/7/8, and ØMQ.  Every framework unsurprisingly doesn't
> support all combinations but I'm working from what is available on the TIBCO
> side, i.e. leveraging location transparency and no single point of failure.
>
> Broadcast Publish-Subscribe, dependent upon an underlying broadcast
> transport, i.e. PGM/IP or PGM/UDP.  TCP being fundamentally flawed due to
> requiring a fixed endpoint.
> Broadcast Request-Reply, the server and client possess location independence
> but multiple running servers would yield multiple responses as each
> receivers the clients query.
> Unicast Publish-Subscribe, feeding from one node to another requiring at
> least one temporally fixed address and introducing a point of faliure.
>  Analogous to ØMQ using a TCP transport with PUB/SUB sockets.
> Unicast Request-Reply, requiring both sides to possess temporally fixed
> addressing and hence two points of failure.  Analogous to REQ/REP sockets
> in ØMQ.
> Fault-Tolerant Request-Reply, extending the broadcast publish-subscribe
> model by implementing fail-over fault-tolerance in the server side.
> Certified Publish-Subscribe, using a ledger publish side and subscriber side
> in order to track receivers and state of confirmed messages.
> Certified Request-Reply, extending ledger usage for client-to-server and
> server-to-client response.  Note TIBCO Rendezvous has a well known flaw with
> tracing certified unicast responses causing the ledger not to be purged.
> Distributed Request-Reply, combining certified and fault-tolerant messaging
> a distributed group of servers is created using fault-tolerance to elect a
> scheduler which uses certified message to dispatch messages to application
> workers.  Failure of the scheduler is a point of failure causing dropped
> messages.  Matches ØMQ's PUSH/PULL sockets that implement a load-sharing
> group of receivers, however ØMQ still requires a temporally fixed endpoint
> address.
> Certified Distributed Request-Reply, adding certified messaging from the
> client through to the application worker.  Failure of the scheduler defers
> recovery to the client ledger.  When configured with a memory ledger is
> functionally equivalent to disk spooled ØMQ PUSH/PULL sockets with fixed
> identities, however common configuration is a disk ledger which can continue
> message delivery independent of client and server restarts.  If the
> application crashes the ledger will be corrupted and therefore applications
> must use an external transaction manager to implement guaranteed once-only
> delivery.  Note that ØMQ has a major issue that messages delivered to the
> receiver but not processed by the application will be lost upon failure,
> only undelivered messages are held in queue.
>
> Not sure how all of this is going to be organised, but an FYI anyhow and
> someone can point out any incorrect understanding of ØMQ sockets.
> --
> Steve-o
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>