I think this an interesting distinction, between RPC and simple queues.
RPC relies on a client calling on a known remote server, where simple
queues allow a horde of workers to pull messages off as they are
available. I can see a use case for either depending on scale.
I'm unforgivably implementation-oriented, but: whaa?
a queue requires an RPC to enqueue and an RPC to dequeue, so it's not as if
there is any difference in scalability, security or local/remote-ness.
ie enqueing is a sort of fire-and-forget RPC that doesn't do any work.
I guess the main difference is really architectural: with queues as the
building block, you need an out-of-band, "meta" coordinator to track
success/completion, whereas the RPC approach can handle status in-band.
-mark
_______________________________________________
Beowulf mailing list, [email protected] sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
