[nanomsg] Re: [Non-DoD Source] status update libnng

  • From: omid shahraki <dreamstechgroup@xxxxxxxxx>
  • To: nanomsg@xxxxxxxxxxxxx
  • Date: Thu, 12 Jan 2017 04:08:24 -0800

Hi guys,

Considering performance issue, I think we need to start asking questions
and try to figure it out more in detail. Consider an enterprise including
all architectural elements, systems / sub-systems / components / modules /
processes and all the way down to functional units which plenty of
resources (tangible and intangible) dedicated to make it happen. Let's take
this as a holographic universe in our mind and ask "Could there be a demand
for a performance monitoring pattern to get fit in that enterprise without
having major impacts? If there could be a demand, as a Hypothesis, how it
could be rejected? If not, what we are going to exchange for this
opportunity or what would be the opportunity cost for such decision
making?..."

It is not only about "inproc" which could be used in local structural
pattern building but it is about designing in a SMART way. Ans you already
know about that! Measurement as one of its core elements shine out when we
encounter bottle-necks by which whole enterprise could experience risk that
no compensation overseen for it.

Are you paying attention?
It is not always about speed. How fast is fast? Is it really fast? Speed is
just one of the problem solvents in solution space.

Omid Shahraki
------------------------------------------------------------------

On Jan 6, 2017 22:25, "Karan, Cem F CIV USARMY RDECOM ARL (US)" <
cem.f.karan.civ@xxxxxxxx> wrote:

Sounds good.  I agree that arrays are the fastest method, and I suspect
that once subscriptions are set up, they will stay stable over long time
periods.  So, yes, **in theory** an array is worse than a Patricia tree,
etc., but I expect that in practice the arrays will win big.

Thanks,
Cem Karan

-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
On Behalf Of Garrett D'Amore
Sent: Friday, January 06, 2017 1:33 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [Non-DoD Source] status update libnng

All active links contained in this email were disabled. Please verify
the identity of the sender, and confirm the authenticity of all links
contained within the message prior to copying and pasting the address to
a Web browser.


________________________________



Oh, I convinced myself that an array is better.  What’s even cooler, is
that using an array, I can use a binary search to get filtering
operations back to O(log(n)).  Changing subscriptions will still be
somewhat expensive, but I think that won’t be too bad since I can reduce
it to the cost of memcpy(), where the size being copied is basically a
pointer and a size (at most 16 bytes total typically) per subscription.
This means if you have 1000 subscriptions I might have to memcpy 16k
when you change the subscription.  But most of the time we’ll be
looking at shuffling around a couple of hundred bytes at most.
(Allocations are still an issue, but I think I can keep that down to minimum
— preallocating 16 slots or so to start, and doubling each we find we
need more.)

On Fri, Jan 6, 2017 at 10:19 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
<cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:


      I agree with what you're saying, but I was thinking of somewhat
simpler testing; whether or not an array/list/Patricia tree are
better in the real world.  The higher-order stuff is, as you point out,
really, really complicated to test.

      Thanks,
      Cem Karan

      > -----Original Message-----
      > From: nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  [Caution-mailto:nanomsg-
bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ]
On Behalf Of Garrett D'Amore
      > Sent: Friday, January 06, 2017 11:30 AM
      > To: nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx

      > Subject: [nanomsg] Re: [Non-DoD Source] status update libnng
      >
      > All active links contained in this email were disabled. Please
verify the identity of the sender, and confirm the authenticity of all
links
      > contained within the message prior to copying and pasting the
address to a Web browser.
      >
      >
      > ________________________________
      >
      >
      >
      > Performance statistics are hard to gather somewhat, and harder
to use generically.
      >
      > The difficulty of gathering is that you need to measure entire
latency; really you want to modify the wire protocol to carry
timestamps.
      > Some performance data we can report, such as queue depth, etc.
      >
      > The difficulty of use is that everyone’s system and applications
are so wildly different that what might be perfectly normal for
one user
      > might be tragically bad for another.
      >
      > In actuality, there has been very little demand for
performance-related bug analysis, I can recall precisely one user over he
years
griping
      > about inproc performance vs. ZMQ.  My response at the time was
“I don’t care”.  (Because inproc performance was never
terribly
      > important to me since I don’t think it sees much real world use,
and I also had bigger fish to fry around trying to fix the MT-
safety things in
      > inproc.  libnng is me basically giving up on that. I couldn’t
figure out how to make libnanomsg’s inproc completely thread-safe
without
      > completely trashing the performance.  The FSM architecture made
passing data across the different sockets (which had different
lock
      > hierarchies) too damned difficult.
      >
      > On Fri, Jan 6, 2017 at 7:00 AM, Karan, Cem F CIV USARMY RDECOM
ARL (US) <cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;>  < Caution-
      > Caution-mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:
cem.f.karan.civ@xxxxxxxx >  > > wrote:
      >
      >
      >       You were mentioning that you were planning on adding
statistics gathering code; have you considered adding code that
gathers
      > performance statistics as well?  As end users we could send you
bug reports that include those statistics, which would let you
know if it’s a
      > problem or not.
      >
      >       Thanks,
      >       Cem Karan
      >
      >       > -----Original Message-----
      >       > From: nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg-bounce@
freelists.org >  >  [Caution-Caution-mailto:nanomsg- ;<
Caution-mailto:nanomsg- ;>
      > bounce@xxxxxxxxxxxxx < Caution-mailto:bounce@xxxxxxxxxxxxx ;>  <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  > ] On Behalf Of Garrett
D'Amore
      >       > Sent: Thursday, January 05, 2017 1:37 PM
      >       > To: nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@
freelists.org >  < Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>  >
      >       > Subject: [nanomsg] Re: [Non-DoD Source] status update
libnng
      >       >
      >       > All active links contained in this email were disabled.
Please verify the identity of the sender, and confirm the authenticity
of all
      > links
      >       > contained within the message prior to copying and
pasting the address to a Web browser.
      >       >
      >       >
      >       > ________________________________
      >       >
      >       >
      >       >
      >       > I could certainly make it an array. :-)
      >       >
      >       > If it seems to be universal that nobody needs more than
a few hundred of these things, I’ll switch to an array.
      >       >
      >       > I wasn’t so much worried about list traversal times as I
was about the O(n) vs O(log(n)) thing though.  If we know that O(n)
is
      > good
      >       > enough, then certainly an array is probably going to be
superior.  One thing about an array, is that if I keep it sorted, then
      > subscribe
      >       > operations will become more expensive, since I’ll have
to shuffle on average half the items in the array.  I’m assuming
      > subscription
      >       > changes occur less frequently than messages arrive.
(I’d really like to know if anyone has an application where changes to
      > subscriptions —
      >       > subscribe/unsubscribe — is a performance sensitive
operation.)
      >       >
      >       >  - Garrett
      >       >
      >       >
      >       > On Thu, Jan 5, 2017 at 10:23 AM, Daniel C <
danielcccc@xxxxxxxxx < Caution-mailto:danielcccc@xxxxxxxxx ;>  < Caution-
Caution-mailto:danielcccc@xxxxxxxxx ;< Caution-mailto:danielcccc@
gmail.com >  >  < Caution-
      > Caution-Caution-mailto:danielcccc@xxxxxxxxx ;< Caution-mailto:
danielcccc@xxxxxxxxx >  < Caution-Caution-
mailto:danielcccc@xxxxxxxxx ;< Caution-mailto:danielcccc@xxxxxxxxx ;>  >
wrote:
      >       >
      >       >
      >       >       I agree with Jason; an array would be faster. N
definitely less than 10 or 20 in my case.
      >       >
      >       >
      >       >       Dan
      >       >
      >       >
      >       >       On Thu, Jan 5, 2017 at 7:58 AM, Jason E. Aten <
j.e.aten@xxxxxxxxx < Caution-mailto:j.e.aten@xxxxxxxxx ;>  < Caution-
Caution-mailto:j.e.aten@xxxxxxxxx ;< Caution-mailto:j.e.aten@xxxxxxxxx
 >  < Caution-
      > Caution-Caution-mailto:j.e.aten@xxxxxxxxx ;< Caution-mailto:
j.e.aten@xxxxxxxxx >  < Caution-Caution-
mailto:j.e.aten@xxxxxxxxx ;< Caution-mailto:j.e.aten@xxxxxxxxx ;>  >  > >
wrote:
      >       >
      >       >
      >       >               For a small N < 10, I would expect an
array to be much faster than a linked list.
      >       >
      >       >               My typical use is for small N, about 3.
      >       >
      >       >               On Thu, Jan 5, 2017 at 4:52 AM, Garrett
D'Amore <garrett@xxxxxxxxxx < Caution-mailto:garrett@xxxxxxxxxx ;>
< Caution-Caution-mailto:garrett@xxxxxxxxxx ;< Caution-mailto:
garrett@xxxxxxxxxx >  >  <

      > Caution-Caution-Caution-mailto:garrett@xxxxxxxxxx ;<
Caution-mailto:garrett@xxxxxxxxxx ;>  < Caution-Caution-
mailto:garrett@xxxxxxxxxx ;< Caution-mailto:garrett@xxxxxxxxxx ;>  >  > >
wrote:
      >       >
      >       >
      >       >                       TCP works now.  OMG, close() vs.
accept() is such a non-portable nightmare.  I almost went down the path of
      >       > pthread cancellation.  Thankfully, that crisis is now
averted.  I never realized just how broken the use of UNIX file
descriptors in
      > the face of
      >       > close() and multiple threads really are.  But its
working now . Thank goodness for shutdown(2) and dup2().
      >       >
      >       >                       There’s a test suite for TCP and
inproc, and I’ve started PUB/SUB.  Sub is actually done, untested.
      >       >
      >       >                       I give 50/50 odds on me finishing
up the remaining protocols and IPC before the weekend.
      >       >
      >       >                       What won’t happen before the
weekend is writing the eventing framework (necessary for file descriptor
based
      >       > notifications for example), or statistics framework.
And Windows will probably happen next week.  I’ve designed this such
that I
      > think I
      >       > will be able to crank out Windows stuff super fast.
      >       >
      >       >                       One question about PUB/SUB.  I’ve
for now used a simple sorted linked list for subscriptions.  My instinct is
that
      >       > for the vast vast majority of folks, this is not only
sufficient, but probably superior to a patricia tree;  I think most of us
only
      > maintain
      >       > around a dozen or so subscriptions on any subscriber at
any given time.  That said, I’m keen to hear of actual uses of
nanomsg
      > where the
      >       > patricia tree makes a real difference — cases with over
several hundred active subscriptions on a given end node.  (Note
that
      > this is only
      >       > on the the end node; a server can service many many
clients — thousands — each having dozens of subscriptions — with
zero
      > negative
      >       > impact in my design.)
      >       >
      >       >                       To be clear, the linked list means
that filtering messages is now an O(n) instead of O(log(n)) operation (where
n is
      >       > the number of active subscriptions); I suspect that for
small values of n, the linked list approach I’ve taken is faster.  I have
      > implemented
      >       > this way for now for expediency, but I’m open to pulling
in a patricia tree if there is need.   (I didn’t yank Martin’s old code
      > because I want
      >       > to make sure I thoroughly understand it before I bring
it into the new code base — I haven’t had time to be certain of that
yet.
      >       >
      >       >
      >       >                       On Wed, Jan 4, 2017 at 2:18 AM,
Garrett D'Amore <garrett@xxxxxxxxxx < Caution-
mailto:garrett@xxxxxxxxxx ;>  < Caution-Caution-mailto:garrett@xxxxxxxxxx
< Caution-mailto:garrett@xxxxxxxxxx ;>  >

      > < Caution-Caution-Caution-mailto:garrett@xxxxxxxxxx ;<
Caution-mailto:garrett@xxxxxxxxxx ;>  < Caution-Caution-
mailto:garrett@xxxxxxxxxx ;< Caution-mailto:garrett@xxxxxxxxxx ;>  >  >
      >       > > wrote:
      >       >
      >       >
      >       >                               I’ve just committed the
initial swag at TCP.  Turns out it was bit more code than anticipated, as I
want to
      >       > support TCPv4 and TCPv6, and properly support different
platforms that might have different ways to resolve names, or
handle
      > low level
      >       > TCP details.  This should make it really fast to write
the winsock code later.
      >       >
      >       >                               I’ve also tried to
abstract the details so that transports that want to build on top of TCP
(e.g. websocket
      >       > or TLS) can do so easily.
      >       >
      >       >
      >       >                               Totally untested, but you
can look at the last commit if you want to see what I’m up to.  The main
missing
      >       > thing (besides testing that it actually works) is
support for some of the richer TCP options — e.g. KEEPALIVEs etc.  I am
disabling
      > Nagle by
      >       > default, because I think 99% of nanomsg users have no
business wanting Nagle turned on.  (And I’ve taken care to use
writev to
      > avoid
      >       > splitting writes up across separate packets when
possible.  This is something that sadly isn’t possible using Go….)
      >       >
      >       >                               On Tue, Jan 3, 2017 at
10:54 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
      >       > <cem.f.karan.civ@xxxxxxxx < Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  >  < Caution-Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  <
      > Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>  >  > > wrote:
      >       >
      >       >
      >       >                                       Got it, my brain
glitched and forgot that inproc is a thing; for some reason I thought you
were
      >       > building out your own TCP stack, which would have made
me... concerned. ;)
      >       >
      >       >                                       Thanks,
      >       >                                       Cem Karan
      >       >
      >       >                                       > -----Original
Message-----
      >       >                                       > From:
nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx
 <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  >  < Caution-
      > Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg-bounce@
freelists.org >  >  >
      >       > [Caution-Caution-Caution-mailto:nanomsg-bounce@
freelists.org < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  >  < Caution-Caution-
      > Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg-bounce@
freelists.org >  >  > ] On Behalf Of Garrett D'Amore
      >       >                                       > Sent: Tuesday,
January 03, 2017 1:23 PM
      >
      >       >                                       > To:
nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>  <
Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 < Caution-Caution-
      > Caution-mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@
freelists.org >  < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 >
      >       >                                       > Subject:
[nanomsg] Re: [Non-DoD Source] status update libnng
      >       >                                       >
      >       >                                       > All active links
contained in this email were disabled. Please verify the identity of the
sender,
      >       > and confirm the authenticity of all links
      >       >                                       > contained within
the message prior to copying and pasting the address to a Web browser.
      >       >                                       >
      >       >                                       >
      >       >                                       >
________________________________
      >       >                                       >
      >       >                                       >
      >       >                                       >
      >       >                                       > I’m about 24
hours from having TCP working.  Right now the TCP transport is not written,
      >       > though I’ve written a fair bit of it locally.
      >       >                                       >
      >       >                                       > The REQ/REP
pattern is working now, as is PAIR, and inproc is working quit well and
totally
      >       > thread safe.
      >       >                                       >
      >       >                                       > As far as
lockless algorithms go — I’m a big believer in mutexes.  I need mutexes and
condition
      >       > variables to make things work well, and in
      >       >                                       > my experience if
they are used sensibly (with minimal contention), they do not significantly
      >       > impact performance.
      >       >                                       >
      >       >                                       > For some things
lockless data structures are superior, but you have to have use cases that
work
      >       > for them; with mutexes and condvars I
      >       >                                       > don’t have to
think about this; they Just Work.
      >       >                                       >
      >       >                                       > It may be useful
to look at alternative designs for that in the future, but I’m only going
to do
      >       > that once I’ve demonstrated a clear need or
      >       >                                       > benefit (or
maybe someone else will contribute at that point).  Until then, I need to
focus on
      >       > getting the code working with a sensible
      >       >                                       > design and avoid
prematurely optimizing things.
      >       >                                       >
      >       >                                       >   - Garrett
      >       >                                       >
      >       >                                       >
      >       >                                       > On Tue, Jan 3,
2017 at 6:45 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
      >
      >       > <cem.f.karan.civ@xxxxxxxx < Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  >  < Caution-Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  <
      > Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>  >  >  < Caution-
      >       >                                       >
Caution-Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;>  < Caution-Caution-mailto:cem.f.
karan.civ@xxxxxxxx < Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>  >  <
      > Caution-Caution-Caution-mailto:cem.f.karan.civ@xxxxxxxx ;<
Caution-mailto:cem.f.karan.civ@xxxxxxxx ;>  < Caution-Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;< Caution-mailto:cem.f.karan.
civ@xxxxxxxx >  >  >  > >
      >       > wrote:
      >       >                                       >
      >       >                                       >
      >       >                                       >       >
-----Original Message-----
      >       >                                       >       > From:
nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx
 <
Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  >  <
      > Caution-Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  < Caution-
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  >  >
      >       > < Caution-Caution-Caution-Caution-mailto:nanomsg-bounce@
freelists.org < Caution-mailto:nanomsg-
bounce@xxxxxxxxxxxxx >  < Caution-Caution-mailto:nanomsg
-bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  >
<
Caution-
      > Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg-bounce@
freelists.org >  >  >  >  [Caution-Caution-
      >       > Caution-Caution-mailto:nanomsg- ;< Caution-mailto:
nanomsg- >  < Caution-Caution-mailto:nanomsg- ;< Caution-
mailto:nanomsg- ;>  >  < Caution-Caution-Caution-mailto:nanomsg- ;<
Caution-mailto:nanomsg- ;>  < Caution-Caution-mailto:nanomsg- ;<
Caution-mailto:nanomsg- ;>  >  >
      >       >                                       >
bounce@xxxxxxxxxxxxx < Caution-mailto:bounce@xxxxxxxxxxxxx ;>  <
Caution-Caution-
mailto:bounce@xxxxxxxxxxxxx ;< Caution-mailto:bounce@xxxxxxxxxxxxx ;>  >
< Caution-Caution-
      > Caution-mailto:bounce@xxxxxxxxxxxxx ;< Caution-mailto:bounce@
freelists.org >  < Caution-Caution-mailto:bounce@xxxxxxxxxxxxx ;<
Caution-mailto:bounce@xxxxxxxxxxxxx ;>  >  >  < Caution-Caution-
      >       > Caution-Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;>  < Caution-
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  >  < Caution-Caution-
      > Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:
nanomsg-bounce@xxxxxxxxxxxxx >  < Caution-Caution-
mailto:nanomsg-bounce@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg-bounce@
freelists.org >  >  >  > ] On Behalf Of Garrett D'Amore
      >       >                                       >       > Sent:
Monday, December 26, 2016 2:46 AM
      >       >
      >       >                                       >       > To:
nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>  <
Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 < Caution-Caution-
      > Caution-mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@
freelists.org >  < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 >  < Caution-Caution-
      >       > Caution-Caution-mailto:nanomsg@xxxxxxxxxxxxx ;<
Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>  < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 < Caution-Caution-

      > Caution-mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@
freelists.org >  < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
 >  >
      >
      >       >                                       >       > Subject:
[Non-DoD Source] [nanomsg] status update libnng
      >       >                                       >       >
      >       >                                       >       > Just a
brief Christmas (western) update…
      >       >                                       >       >
      >       >                                       >       > libnng
is now managing connections.  There’s a lot more to this than you’d think —
and a
      >       > lot of details that I’ve written under
      >       >                                       > the hood.
      >       >                                       >       >
      >       >                                       >       >  I
expect that by New Years I’ll have it in a functional state for TCP for
POSIX systems, for
      >       > at least the primary patterns /
      >       >                                       > protocols.  TBH,
      >       >                                       >       > I’m
really only a couple of hours from that point.
      >       >                                       >       >
      >       >                                       >       > Note
that the current code base is pretty much crash-immune with respect to
things that
      >       > caused grief in libnanomsg — e.g.
      >       >                                       > ENOMEM
      >       >                                       >       > errors
will not impact libnng.  The whole approach has been from a “correct
first”, so I
      >       > expect we will have fewer problems once
      >       >                                       > we
      >       >                                       >       > actually
start using this.
      >       >                                       >       >
      >       >                                       >       > Things
are moving apace… quite quickly actually.
      >       >                                       >       >
      >       >                                       >       > If
anyone is so inclined to review or give feedback on teh existing code, I’m
now at the
      >       > point to receive it, understanding that
      >       >                                       > there are
      >       >                                       >       > still
large swathes still unimplemented.  You can’t use it for TCP for example.
But at this
      >       > point I’d rather solicit feedback early
      >       >                                       > rather than
      >       >                                       >       > late.
Don’t tell me what’s missing, but if you see problems with what’s already
there,
      >       > please *do* let me know.
      >       >                                       >       >
      >       >                                       >       > I’m
going on a ski trip for the next several days, but will probably work in
the evenings
      >       > getting the thing to a state where other
      >       >                                       > folks can
      >       >                                       >       > start
playing with for actual experimentation.
      >       >                                       >       >
      >       >                                       >       > I’m
really looking forward to benchmarking this thing.  I think we’re gonna
blow the doors
      >       > off libnanomsg, at least for platforms
      >       >                                       > that have
      >       >                                       >       >
non-crappy pthreads. :-)
      >       >                                       >       >
      >       >                                       >       > Merry
Christmas everyone! :-)
      >       >                                       >
      >       >                                       >       Thank you
for all your hard work!
      >       >                                       >
      >       >                                       >       BTW, when
you say that you can't use it for TCP, what exactly do you mean?
      >       >                                       >
      >       >                                       >       Thanks,
      >       >                                       >       Cem Karan
      >       >                                       >
      >       >                                       >
      >       >                                       >
      >       >
      >       >
      >       >
      >       >
      >       >
      >       >
      >       >
      >
      >
      >





Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 01-2017