[zeromq-dev] Formally modelling the publish-subscribe pattern

[Brett Viren]

John Lång <john.lang at mykolab.com> writes:

> Thanks for your answer!

And, thanks to Bill Torpey's reply, I should clarify I only had TCP
transport in my mind.

> I should have mentioned that I'm approximating something like HWM 1
> because buffering would explode the state space of my model very
> badly. The model already takes hundreds of gigabytes of RAM with some 
> properties and parameters.

Wow, that's some modeling!  I don't at all grasp how this formal
modeling works but I guess in most practical applications a HWM of 1
would not be very,... well,... "practical".

> You're right. This is application-specific. I meant to say that in my
> application, subscribers just switch to another publisher if the 
> connection dies. I have redundant publishers and subscribers. Is there
> some timeout parameter to detect if the publisher just vanishes?

Not that I know of.  The relevant RFC[1] does not specify anything.

But, an application may always store the system time when the last
message was recv()'ed from the SUB and periodically compare that to the
"now" time and then do something if their difference becomes "too
large".


Hmm, actually I see zmq_socket_monitor() has[2] a ZMQ_EVENT_DISCONNECTED
event.  It seems it would allow an app with a SUB to react directly to a
PUB death without the need to maintain an app-level timeout.

I have never used the socket monitor so don't know its subtleties.  In
particular, I'd wonder if the "disconnected" event is generated after
some internal timeout and if so if that would need to be featured in
your modeling.


-Brett.

[1] https://rfc.zeromq.org/spec/29/#the-sub-socket-type
[2] http://api.zeromq.org/master:zmq-socket-monitor
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 849 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20210603/5d0c41ee/attachment.sig>