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> 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-----On Behalf Of Garrett D'Amore
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Sent: Monday, December 05, 2016 2:46 PMrun nanomsg on a simulator
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [Non-DoD Source] Re: Modifications necessary to
the identity of the sender, and confirm the authenticity of all links
All active links contained in this email were disabled. Please verify
contained within the message prior to copying and pasting the address toa Web browser.
in a single process, which itself can be multi-threaded.
________________________________
You could have a huge number of goroutines (and yes they are coroutines)
with C. You could use channels, though I wouldn’t necessarily recommend
If you can use Go, then a lot of your life will be easier than it is
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 performanceoptimal, but this would give you the ability to use nanomsg’s
messaging patterns (including patterns for broadcasting via BUS ormangos’ custom STAR protocol), as well as some extras that mangos
gives you that nanomsg lacks. (For example, it *is* possible toterminate a particular connection, or a whole endpoint — in mangos at any
time.)to accelerate the performance of inproc. (Sadly it still does data
Mangos will be changing to use net.Pipe for inproc as well, doing more
copies, but at least we will be eliminating the use of channels.)multiple real-world computers, which might make it reasonable
One other advantage of using mangos is that you can then use this with
to use the same messaging for real-world robots in the future. It wouldalso let you use multiple-process & multiple-system concurrency
to let you build really massive systems (limited only by how manycomputers you can bring to bear.)
<cem.f.karan.civ@xxxxxxxx < Caution-
- Garrett
On Mon, Dec 5, 2016 at 11:35 AM, Karan, Cem F CIV USARMY RDECOM ARL (US)
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:nanomsg-bounce@xxxxxxxxxxxxx > [Caution-mailto:nanomsg-
> -----Original Message-----
> From: nanomsg-bounce@xxxxxxxxxxxxx < Caution-mailto:
bounce@xxxxxxxxxxxxx < Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ]On
> Behalf Of Jason E. Atenfreelists.org > >
> Sent: Monday, December 05, 2016 1:52 PM
> To: nanomsg <nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@
> Subject: [nanomsg] Re: [Non-DoD Source] Re: Modificationsnecessary to run
> nanomsg on a simulatorcalled for at
>
> Hi Cem,
>
> For a simulation I don't see why any actual networking code is
> all. With a dissertation the conclusion/theory matters and theout. If it
> implementation should rarely be fully fleshed out.
You're right, I just wanted to make my dissertation really stand
is difficult to get nanomsg to do what I want, I'll continue withwhat I have
and fake it.mathematics of
> I would skip the implementation details and simply model the
> the simulation using matrices in Matlab or R.it still
Matlab and R are too slow (I tried python and Numpy at one point,
couldn't handle it).goroutines
> Only if more is required, then model it in Go using channels and
> (1-3 goroutines per robot), but -- really -- only if required.100K robots
> Again you can do this on a single host, and still be modeling
> (300K goroutines) without a problem.close to that
Goroutines are coroutines, correct? I've got something pretty
in C by storing all current state information about a robot withinits own
struct (fake class instance). When a robot is activated, it firstchecks its
state, and then decides what to do next. That said, if I waswriting the
simulator from scratch today, goroutines (or any other languagethat had good
coroutine support) would DEFINITELY make some aspects easier!however you
> Anyway, just a friendly observation. Best of luck with the work
> go at it.
Thank you!
Thanks,
Cem Karan