Sorry about previous top post, and this double post.
Hi Feng,
I'm glad to hear about your experiments and ideas. Could elaborate on the last comment that I've quoted above, re "not too keen on sending messages to remote threads." I think I must be misunderstanding something, because the whole point of ZMQ is to send messages to remote threads. I'm also not clear what you mean by the terms subject-oriented message vs. too tightly coupled. Feel free to elaborate on these, if you can.
Thank you.
Best regards,
Jason
Hi Jason,
I meant to send messages to a specific thread _identity_. A receiver thread has to expose its identity (a pid or tid) on network in order to provide a service. Sender thread has to get hold of specific receiver thread's identity to ask for a service - tightly coupled (not much different from distributed object).This is useful model within local process, where shared state allow them to find each other easily. More important, message delivery is guaranteed, and peer errors can be handled easily. However, these properties become much difficult in distributed network. An architecture works better in distributed environment would be any threads in a cluster of gambit process nodes that can offer data or service on a subject just bind himself to a well known url (e.g. tcp://weather.com/va/reston/today, or pgm://stocktick.com/apple), can be one, two, or ten threads, they can come and go anytime as long as someone else take over their duty. Any threads consume services or data just send request message to well known urls, or simply bind their mailbox to them. Yes, ultimately 0mq delivers messages to gambit thread, but it decouples sender and receiver's identity.
Hope this make some sense.
Cheers,
- Feng