0

With a single publisher(go-routine) and multiple subscribers(go-routine) on same machine, below message hub help create pubsub model:

type PublisherHub struct { 
  subscribers map[*subscribmediator.Subscription]struct{} // each subscriber is local to same machine
  Register    chan *subscriptionmediator.Subscription // register a subscriber
  Unregister  chan *subscriptionmediator.Subscription
  Broadcast   chan *data // broadcast data to all subscribers
}

Language used is GoLang. Environment is Linux.

If a subscriber is sitting remote to publisher and does not use http protocol, then,

does pubsub pattern still a relevant pattern to use? with publisher on one machine & each subscriber on a different machine....

If no, what is the alternate design pattern?

1

PubSub by another name is a call back.

It does not matter how the two communicate: http, functions, tcp, parallel wires, usb, etc...

They don't even have to have the same communication system for registration and the call back. Its perfectly okay to register via http, and receive data back via usb, vice versa or any other combination.

What is needed is some special information.

  • This special information is what the subscriber provides to the publisher on registration.
  • This special information is also what is required for the publisher to transmit information back to the subscriber at some point in the future.

In the case of http, the special information is the ip, port, and whatever other configuration is required to get the right data, in the right format, sent to that ip and port.

| improve this answer | |
  • But I still see the issue of lack of robustness to extend Pubsub model on wire. Instead maintain a database as shared state and both publisher and subscriber talk to that database – overexchange Sep 15 at 9:53
  • Something like this: youtu.be/TU8yNh5JCyw – overexchange Sep 15 at 10:02
  • Forgive me my inability to watch a youtube video from this machine. The PubSub model is inherently brittle. Subscribers go down, publishers too, intermediaries may alter data, and the communication channels between them shift outdating the information provided on registration. But that is why you use other tricks such as sequence markers, and clients who on an interval poll (and reregister) if they have not received a recent heart beat message. If you dig into the details of how databases achieve this, it will boil down to some implementation of both techniques. – Kain0_0 Sep 15 at 11:44
  • Please also comment on this query...stackoverflow.com/q/64015056/3317808 – overexchange Sep 23 at 4:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.