[zeromq-dev] Fundamental perks?

Kenneth Adam Miller kennethadammiller at gmail.com
Thu May 14 15:34:33 CEST 2015


Great, these are excellent points. I can use this!

On Thu, May 14, 2015 at 9:34 AM, Kenneth Adam Miller <
kennethadammiller at gmail.com> wrote:

> Oh thank god! Someone that understands!
>
> On Thu, May 14, 2015 at 4:11 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> Why even use an operating system? It's far safer to write the code
>> straight into hardware.
>>
>> Seriously, anyone trying do build distributed systems who is not using
>> some kind of abstraction layer because of the extra dependency is... well,
>> they've not understood the different costs / benefits.
>>
>> Without a messaging library of some kind you have to deal with dozens or
>> hundreds of issues in every single connection. The BSD socket API is very
>> low level. You have to handle all kinds of errors, some by retrying, some
>> by giving up, some by trying something different. To get any performance at
>> all you must build an event-driven framework so you can read and write as
>> sockets are ready, rather than blocking. To deal with more than a single
>> socket this becomes essential. Then you have to frame your data and deal
>> with edge cases and invalid data.
>>
>> At the least you want to hide this from developers, because they will get
>> it wrong over and over, and this causes far worse complexity and
>> dependencies than using a mature and proven library.
>>
>> it's easy to count. Hand-written TCP code measures thousands of lines for
>> any given case. The same code using a messaging API counts a few dozen.
>> Now, whether you use ZeroMQ or something else is secondary. ZeroMQ removes
>> the need for brokers, though they can help in some cases.
>>
>> When you introduce technology to a business you will often get resistance
>> for reasons that have nothing to do with the technology itself.
>>
>> -Pieter
>>
>>
>>
>> On Thu, May 14, 2015 at 6:33 AM, Kenneth Adam Miller <
>> kennethadammiller at gmail.com> wrote:
>>
>>> So, recently in the workforce the discussion came up that despite all of
>>> the nice work that has been accomplished with ZMQ, it should be removed
>>> because using it as a component for distributed analysis creates
>>> complication. Much to my dismay, they cannot be convinced otherwise, and
>>> see dependencies only as potential breakage and configuration nightmare.
>>>
>>> But our use case still needs to communicate between processes in the new
>>> model proposed. The idea is for regular raw sockets to be used to
>>> communicate between processes, because this would be the only
>>> communication, and the linux kernel would automatically replace any
>>> localhost communication with inter process communication (?).
>>>
>>> What fundamental benefits in such a use case does using ZMQ provide?
>>> Things like OS interrupts, OS abstraction, ect... I'm pretty sure that ZMQ
>>> does at least hide some complexity in buffering what it receives.
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150514/707f0f00/attachment.htm>


More information about the zeromq-dev mailing list