[nanomsg] Re: nanomsg: the big picture
- From: Alex Milos <alex.milos@xxxxxxxxxxx>
- To: public-nanomsg-uGLqWuYN4qMgsBAKwltoeQ@xxxxxxxxxxxxxxx
- Date: Wed, 15 Jan 2014 04:03:15 +0400
Hello Martin,
I spent over 2 months studying ZeroMQ just to realize that I like the
philosophy of nanomsg much better (after I read your blog post on C vs
C++ and reading the book The Art of Unix Programming). Still, the
"alpha" status was a warning sign for me up to this point.
I've been reading the mail on comp.lib.nanomsg but have not had a chance
to go over all the threads yet. So I may have missed something important
and what I am about to write is already outdated. Anyway, just by
accident the "big picture" title of your letter caught my attention and,
after reading it, I realized that I would try nanomsg for my project
instead of zeromq despite the "alpha warning."
Cutting to the chase, so to speak, I strongly believe that your letter
deserves better than to be buried on a news server. As it is for me, it
might sound _very_reassuring_ to all others that
-- quote --
> From user's perspective nanomsg is basically done. Although the
> implementation is not perfect yet, the conceptual framework (sockets,
> scalability protocols, topologies, etc.) is unlikely to change in the
> future.
-- end of quote --
So I completely agree that
"> This should be probably written down as a more formal article, "
For now, the only way to see your post is to go here:
http://permalink.gmane.org/gmane.comp.lib.nanomsg/69
(your site mentions only www.freelists.org and
//www.freelists.org/post/nanomsg/nanomsg-the-big-picture
cuts out all the pictures ;) )
So right now I see 2 things that could easily help the project:
* referencing this post at http://nanomsg.org/
* adding gmane mailing list archive to the "Community" page
http://nanomsg.org/community.html as gmane does not cut out the graphics
+ has some nice complementary features.
Regards,
Alex.
On 05-Sep-13 11:07 AM, Martin Sustrik wrote:
> Hi all,
>
> There have been several discussions both on mailing list and on the IRC
> channel that can't be really resolved without understanding the big
> picture of where nanomsg is going. There's an long email about
> monitoring from Paul from yesterday, but also several discussions about
> service discovery, DNS and such are relevant to the topic.
>
> This should be probably written down as a more formal article, however,
> let me just briefly describe the vision at the moment.
>
> From user's perspective nanomsg is basically done. Although the
> implementation is not perfect yet, the conceptual framework (sockets,
> scalability protocols, topologies, etc.) is unlikely to change in the
> future.
>
> However, from administrative perspective almost nothing have been done
> yet and even the very concepts are not defined. And that's what I am
> trying to do here.
>
> The main idea is strictly separating the user API from from the admin
> API, or mechanism from policy, if you will.
>
> To get the idea, think of TCP. The user establishes the connection, then
> sends and receives data, but is completely ignorant about the underlying
> network infrastructure. Is there a simple cable between the two boxes?
> Is there a LAN? Are 10 IP hops involved? Have an intermediary IP router
> crashed somewhere on the path and have it been routed around? The user
> never knows.
>
> Now there are admins who administer the network. These see all these
> components and issues and work hard to make the whole thing working.
> However, the point is that they don't do that directly via IP or TCP.
> They use specialised administrative interfaces such as SNMP.
>
> So, in the end you have two distinct APIs and two clearly delineated
> sets of users: programmers and admins. The former write business logic,
> the latter take care that the infrastructure is working.
>
> Let's apply the above to nanomsg now.
>
> The idea would be to shield the user from the details of the topology
> same way as the TCP user doesn't see all the routers on the path. This
> can be done by user connecting to a topology ("market data feed"),
> rather than to a specific endpoint ("129.168.0.111:5555"):
>
> nn_connect (s, "topology://market-data-feed");
>
> I am not going to disucss implementatation details here, but the idea is
> that admins store the actual info about topology setup in a distributed
> database (such as DNS) and that the library translates
> topology://market-data-feed" into actual endpoint(s) to connect to by
> querying the database.
>
> Thus, from the user perspective, they are connecting to a "cloud" called
> "market-data-feed" without being aware of its internal structure:
>
> [back1.png]
>
> It's up to admins to define the internal structure. During the
> development phase it may be something simple like:
>
> [back2.png]
>
> When deployed to production it may be more complex to account for
> administrative and geographical boundaries:
>
> [back3.png]
>
> The main point is: There's no difference visible to the user between the
> cases. This allows admins to optimise and re-structure the topology
> without affecting the applications.
>
> End of chapter one.
>
> Now forget about users and imagine you are an admin tasked with
> maintaining a topology. What kind of tools do you need to do your job?
>
> First, you need a way to update the distributed database (such as DNS)
> so that you can configure the topology according to your needs.
>
> Second, you need a tool to check whether the topology is working as
> expected.
>
> As for the latter, the statistics from the entire topology must be
> collected and presented to the admin in such a comprehensive way:
>
> [back4.png]
>
> So, the admin looks at the graph above, sees there's an disconnection
> between two intermediary devices and can actually do something about it.
> Is a network connection broken? Or maybe he just set the address wrong
> in the DNS? Etc.
>
> As I want to keep this email as short as possible, I won't elaborate
> further, however, it's easy to see the implications of the conceptual
> model described above. For example, the admin wants to check the
> topology as a whole so querying local logs on individual machines
> probably won't fly.
>
> Martin
_________________________________________________________________
Firemail.de Freemail - 10 GB für Mails und Daten
POP3 und IMAP kostenfrei
http://www.firemail.de/
Other related posts:
