51–58 of 58 posts
Earlier quoted context omitted.
Why are you thankful for the MPL instead of the LGPL? Is there any advantage to the MPL other than being easier to incorporate MPL code into proprietary software?
MPL doesn't have an anti-TiVoization clause. The company I'm working for has a complete ban on (L)GPL3.0 source code.
Earlier quoted context omitted.
MPL doesn't have an anti-TiVoization clause. The company I'm working for has a complete ban on (L)GPL3.0 source code.
Is the ban because your company does TiVoization? If so, then that sounds like the (L)GPL3.0 is working as intended.
My project is an IoT node that requires secured and auditable software up and down the chain. We can't allow user replacement. We acknowledge that the spirit of LGPL3 is for a reason and it works for a lot of parties, just not us.
Earlier quoted context omitted.
Is the ban because your company does TiVoization? If so, then that sounds like the (L)GPL3.0 is working as intended.
Yes, and yes. My project is an IoT node that requires secured and auditable software up and down the chain. We can't allow user replacement. We acknowledge that the spirit of LGPL3 is for a reason and it works for a lot of parties, just not us.
Did anybody compare throughput/latency for these approaches? Edit: ... for the basic zmq patterns PUB/SUB, REQ/REP, Client/Server
Earlier quoted context omitted.
Imo, ZMQ is more of an abstraction with which to design protocols, rather than a message queue ready to use, Kafka-style. I found unexpectedly that I needed to really read the entire manual and work through the worked examples and some of my own to start getting it, rather than the usual incremental read. So, you can set up a protocol using ZMQ such that you become aware when a client times out, and you can set behav…
I don't see what ZMQ abstracts that you don't get in TCP already. Is this all just about having a common cross-language API for TCP? Wasn't "BSD sockets" supposed to be that?
And, the component was just "a component" and not "the purpose" of what I was building, so went with ZMQ.
I'm also highly inexperienced in that area, so ZMQ having a singular, well-written, linear manual was a huge benefit.
Earlier quoted context omitted.
I have used ZeroMQ with C, Dlang, and Python -- mostly for learning. However, I have used NetMQ.. a C# implementation of ZeroMQ in live software and the results are very positive! I used a Pub-Sub pattern for one program to keep users informed on progress of a task, which could have taken hours to complete. They had a GUI program which spits out updates. It worked really well. I was also tasked updating a Till softwa…
In 2014, I was tasked with rebuilding an event processing engine to increase throughput and performance. Used ZeroMQ with C# and also had a very positive experience. It was very easy to build a multi-node, distributed event processing engine (think Apache Flink) that could scale by simply adding more nodes or threads. ZMQ makes coordination and management of messages easy and low-fanfare. In our use case, it was stab…
Earlier quoted context omitted.
that 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?
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. And yes depending how long obey-orders() takes, there are actually two instances of this ambiguity per command - when in the…
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.
Earlier quoted context omitted.
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. And yes depending how long obey-orders() takes, there are actually two instances of this ambiguity per command - when in the…
> 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.…