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

John Lång john.lang at mykolab.com
Thu Jun 3 15:50:53 CEST 2021

Hi Brett,

> And, thanks to Bill Torpey's reply, I should clarify I only had TCP
> transport in my mind.
I also only had TCP in my mind. I should have said that.
> 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". 

I believe the large state space of my model comes from the data and 
redundant processes I'm modelling. I have lots of buffering going on. Of 
course, 0MQ and another protocol that I'm modelling are also 
contributing factors. Model checking usually works best for 
control-intensive and not data-intensive applications.

> 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.

This socket monitor thing sounds like something I should look into if I 
ever get to upgrade my system.

0MQ is a mere complication in my model, though. The main focus is in my 
overall distributed system. I think that 0MQ PUB-SUB deserves a model in 
its own right. I think it would be a great topic for a research paper to 
build a formal model of 0MQ PUB-SUB...


More information about the zeromq-dev mailing list