[nanomsg] Re: [Non-DoD Source] Re: Modifications necessary to run nanomsg on a simulator

  • From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Tue, 6 Dec 2016 09:11:15 -0800

Well have a look at the RFCs.  Stay tuned for more info.

On Tue, Dec 6, 2016 at 6:56 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:

Got it; OK, I'll take a look at Mangos and Go this weekend; for this
iteration of the simulator, I probably will stick with C, just because of
the amount of code I've already written (I'm really down to the last little
bits), but for the future Go sounds like a real contender.

It's a shame that nanomsg can't be easily modified to run on a simulator;
I will regretfully have to drop my idea of using nanomsg on top of my
simulator.  I am **very** interested in seeing nanomsg's underlying bits
modified so that it operates on messages/packets instead of pure streams;
at that point I could rework my simulator so nanomsg could run on top of
it.  We might be able to develop protocols for nanomsg that work on swarms
of real robots! :)

Thanks,
Cem Karan

-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
On Behalf Of Garrett D'Amore
Sent: Monday, December 05, 2016 11:58 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [Non-DoD Source] Re: Modifications necessary to
run nanomsg on a simulator

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.


________________________________



You can easily make your own rate limiting thing on top of net.Pipe
implementing a net.Conn.  I would specifically discourage you from
using channels…  They can be useful, but they’re more about sharing data
between goroutines than doing real communication.

I think it would be pretty darn easy to build a custom mangos transport
to do what you want too.  While it might take you a little bit to
figure out the internals, I can build a simple transport in mangos in an
hour or two probably.  (websocket was built in about 2 hours, then
it took about a day to write all the test validation for certificates…
lol.)

At any rate, *nanomsg* can’t do any of this stuff yet.

  - Garrett


On Mon, Dec 5, 2016 at 11:53 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
<cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:


      I agree that it sounds ideal; the only headache I have is making
sure that EXACTLY the right number of bits have gone down the
pipe during the simulation.  For example, a channel might have a
bandwidth of 1000 bits/second.  If my simulator time is advanced 1
second, I want to make sure that the channel has transmitted 1000 bits;
no more, and no less.  If there is a way to make a GO channel
understand how to do that, then I'm in business, otherwise I've got
headaches.

      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: Monday, December 05, 2016 2:46 PM
      > To: nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx

      > Subject: [nanomsg] Re: [Non-DoD Source] Re: Modifications
necessary to run nanomsg on a simulator
      >
      > 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.
      >
      >
      > ________________________________
      >
      >
      >
      > You could have a huge number of goroutines (and yes they are
coroutines) in a single process, which itself can be multi-
threaded.
      >
      > If you can use Go, then a lot of your life will be easier than
it is with C.  You could use channels, though I wouldn’t necessarily
recommend
      > it for performance critical code (channels turn out to be kind
of slow), but you could build your own thing using net.Pipe().  In
fact, you
      > could use mangos today, which is probably not perfectly
performance optimal, but this would give you the ability to use
nanomsg’s
      > messaging patterns (including patterns for broadcasting via BUS
or mangos’ custom STAR protocol), as well as some extras that
mangos
      > gives you that nanomsg lacks.  (For example, it *is* possible to
terminate a particular connection, or a whole endpoint — in
mangos at any
      > time.)
      >
      > Mangos will be changing to use net.Pipe for inproc as well,
doing more to accelerate the performance of inproc.  (Sadly it still
does data
      > copies, but at least we will be eliminating the use of channels.)
      >
      > One other advantage of using mangos is that you can then use
this with multiple real-world computers, which might make it
reasonable
      > to use the same messaging for real-world robots in the future.
It would also let you use multiple-process & multiple-system
concurrency
      > to let you build really massive systems (limited only by how
many computers you can bring to bear.)
      >
      >  - Garrett
      >
      >
      > On Mon, Dec 5, 2016 at 11:35 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:
      >
      >
      >       > -----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 Jason E. Aten
      >       > Sent: Monday, December 05, 2016 1:52 PM

      >       > To: nanomsg <nanomsg@xxxxxxxxxxxxx < Caution-mailto:
nanomsg@xxxxxxxxxxxxx >  < Caution-Caution-
mailto:nanomsg@xxxxxxxxxxxxx ;< Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>

      >       > Subject: [nanomsg] Re: [Non-DoD Source] Re:
Modifications necessary to run
      >       > nanomsg on a simulator
      >       >
      >       > Hi Cem,
      >       >
      >       > For a simulation I don't see why any actual networking
code is called for at
      >       > all. With a dissertation the conclusion/theory matters
and the
      >       > implementation should rarely be fully fleshed out.
      >
      >       You're right, I just wanted to make my dissertation really
stand out.  If it
      >       is difficult to get nanomsg to do what I want, I'll
continue with what I have
      >       and fake it.
      >
      >       > I would skip the implementation details and simply model
the mathematics of
      >       > the simulation using matrices in Matlab or R.
      >
      >       Matlab and R are too slow (I tried python and Numpy at one
point, it still
      >       couldn't handle it).
      >
      >       > Only if more is required, then model it in Go using
channels and goroutines
      >       > (1-3 goroutines per robot), but -- really -- only if
required.
      >       > Again you can do this on a single host, and still be
modeling 100K robots
      >       > (300K goroutines) without a problem.
      >
      >       Goroutines are coroutines, correct?  I've got something
pretty close to that
      >       in C by storing all current state information about a
robot within its own
      >       struct (fake class instance).  When a robot is activated,
it first checks its
      >       state, and then decides what to do next.  That said, if I
was writing the
      >       simulator from scratch today, goroutines (or any other
language that had good
      >       coroutine support) would DEFINITELY make some aspects
easier!
      >
      >       > Anyway, just a friendly observation. Best of luck with
the work however you
      >       > go at it.
      >
      >       Thank you!
      >
      >       Thanks,
      >       Cem Karan
      >
      >
      >





Other related posts:

  1. Home
  2. nanomsg
  3. Archive
  4. 12-2016