[nanomsg] Re: websocket mapping
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 2 Feb 2015 09:36:16 -0600
> Of course, the obvious answer “the essence of nanomsg is captured in the RFC”
> is both correct and useless… I am wondering more along the lines of:
> 1. What layers do we have in an implementation of nanomsg?
> 2. How do these layers relate to each other? What are the interfaces between
> them?
I know that you said the RFCs are “useless”, but I’m not sure what can be said
beyond them, really. In an implementation of nanomsg we have at least
transport and protocol layers, and both those things are well-defined in the
RFCs. I do not know what other layers would be *necessarily* involved, really,
although we can talk about implementation details of the C library for example.
I guess you could talk about protocols abstractly e.g. what the protocols have
in common and in that case you might look at protocol.h to see how the
interface is defined. However, my implementation is going to have a much
different inner API contract so while I’m sure *something* in there is general,
I’m not sure what it is.
If you want to know “what the essence of nanomsg is”, I think it is providing a
toolkit for “message-based” (as opposed to stream-based) communication.
Further, nanomsg is “high-level”—it provides a lot of application-grade
guarantees like atomicity (messages will either arrive together or not at all)
fragmenting (you can send arbitrarily large messages) ordering (e.g. REQ/REP
have strong order guarantees), etc. So I think those two things are “the
essence of” nanomsg, although that definition is also broad enough to encompass
ZeroMQ, so it’s not really useful for that purpose. Then again I think nanomsg
is really a ZeroMQ that is better across a large number of small details. So a
definition that is broad enough to apply to ZeroMQ is not wrong, in my opinion.
> 3. What have we learned from all the (two so far) different implementations?
> What are best practices for a nanomsg architecture?
What I have learned from doing a lot of work inside mainline is that it is
important to have a flexible architecture, where it is easy to compose things,
and I think the current mainline implementation at least is insufficiently so
to my sensibilities.
You may find a previous thread on that topic to be interesting:
http://comments.gmane.org/gmane.comp.lib.nanomsg/1533
> On Feb 2, 2015, at 2:17 AM, Gonzalo Diethelm (Redacted sender
> "gonzalo.diethelm@xxxxxxxxxxx" for DMARC)
> <dmarc-noreply-outsider@xxxxxxxxxxxxx> wrote:
>
>
>> On 30 Jan 2015, at 17:58, Drew Crawford <drew@xxxxxxxxxxxxxxxxxx
>> <mailto:drew@xxxxxxxxxxxxxxxxxx>> wrote:
>>
>> This is probably as good of a time as any to announce that I’ve started work
>> seriously on a third nanomsg re-implementation, that will sit beside nanomsg
>> and mangos as a third implementation of the protocols. A goal of my
>> re-implementation is to leverage the new socket architecture I posted to
>> this list a few months ago, that is difficult to achieve in core for various
>> reasons. A second goal is to fix a bunch of longstanding minor gripes that
>> are hard to do in the existing codebase.
>
> Hey, this is excellent news. It is also a good chance to bring up a question
> from an “insider at the outside” (I have followed ZeroMQ and nanomsg closely,
> and bounced off ideas with Martin, but it’s been a long time since I have
> done anything with any of them, or contributed to any of the projects).
>
> So, I am wondering what is the essence of a nanomsg implementation, and if
> having a good definition for this would be of help in our documentation and
> in helping newcomers understand what we do. Perhaps answering this question
> would lead to an architectural document and, from there, to a set of module
> documents, one per conceptual piece in nanomsg. I would love to contribute to
> that (yes, I am volunteering).
>
> Of course, the obvious answer “the essence of nanomsg is captured in the RFC”
> is both correct and useless… I am wondering more along the lines of:
> 1. What layers do we have in an implementation of nanomsg?
> 2. How do these layers relate to each other? What are the interfaces between
> them?
> 3. What have we learned from all the (two so far) different implementations?
> What are best practices for a nanomsg architecture?
>
> And so on. I am sure it would have helped me understand nanomsg much more
> easily, had I had such descriptions / diagrams / documents. And I don’t feel
> I know enough about nanomsg to be able to produce these documents on my own.
>
> Cheers,
> Gonzalo Diethelm
>
Other related posts:
