4 ms·
I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming
by mindslight 2y ago
I looked at 0mq et al, and what I couldn't understand is why sockets have a single exclusive type. Like say I want a process that generally sends out streaming broadcast updates, but is also controlled through request-reply. It would need two separate sockets. Then I'd have to reinvent some sort of ordering protocol across the two (as well as program logic to handle the partially-connected state), which would defeat much of the point of using 0mq?
- nurettin 2y agoWithout knowing any details, it sounds like a hard problem whether you use 0mq or not.
- mindslight 2y agoThe problem generally needs to be solved by the transport protocol. Having two sockets communicating in parallel means the problem needs to be solved again.
- exe34 2y agonews = -setup broadcast socket- orders = -setup req rep socket- while 1: ----order = orders.read (with timeout) ----orders.send(ack) ----if order: --------do stuff differently ----news.send(status)
- mindslight 2y agoAnd then how does a client know whether an `order` was processed before or after a specific `status`? If you start talking about adding sequence numbers or duplicating application data between `status` and `order` (and its reply), that's the creation of an ad-hoc ordering protocol I'm talking about.
- exe34 2y agothat doesn't sound like a socket level problem, it's more like an application level problem? how long does it take to obey-orders()? do you want to keep spitting out logs while doing it? maybe give orders a number, and the logs can include the order number and the progress?
- mindslight 2y agoIt's a problem that the transport level would normally solve and then provide a single coherent stream to the higher layer. But with 0mq providing multiple parallel streams between each pair of endpoints means that events from each of those streams aren't necessarily received in relative order. And yes depending how long obey-orders() takes, there are actually two instances of this ambiguity per command - when in the log stream did the call start happening, and when in the log stream did it finish. Assigning serial numbers to commands on the request-reply channel and then having the log channel publish those serials is exactly the type of having to invent an ad-hoc ordering protocol that I was talking about. Of course this can be done, but at the expense of adding accidental complexity and unnecessary resource usage. There's a similar problem with MQTT where the spec explicitly disclaims the ordering of messages across topics. Lots of people just ignore this and write software that works perfectly fine in the real world where messages generally get transported in order anyway. But it's still technically incorrect and strikes me as a breeding ground for Heisenbugs.
- exe34 2y ago> mindslight 21 hours ago | root | parent | next [–] It's a problem that the transport level would normally solve and then provide a single coherent stream to the higher layer. But with 0mq providing multiple parallel streams between each pair of endpoints means that events from each of those streams aren't necessarily received in relative order zeromq isn't forcing you to use multiple streams. you can just use one. reqrep, send your command, wait for the response after it's done.
- mindslight 2y agoAnd then how does that client receive the broadcast updates? (`status`)