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

  • From: "Karan, Cem F CIV USARMY RDECOM ARL (US)" <cem.f.karan.civ@xxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Mon, 5 Dec 2016 16:02:23 +0000

-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of SGSeven Algebraf
Sent: Monday, December 05, 2016 9:32 AM
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] Re: Modifications necessary to run 
nanomsg on a simulator

Hi Karan,

You have not told us much about your simulator. I assume that you will write 
it yourself. Which language do you use for your simulator?
Generally speaking nanomsg can be used on all kinds of platforms with many 
languages. I see no restrictions at all.

My apologies.  I am currently writing it.  It is 100% C11 code.

The simulator encapsulates a very simple radio communications model; there are 
multiple independent radio channels, each of which has a fixed bandwidth and 
communications radius.  Robots can only communicate if they are both members 
of the same communications channel.  A robot can be a member of many different 
channels at once.

Within a given channel, if two robots are at a distance <= the communications 
radius, then they can communicate at the channel's bandwidth, otherwise they 
can't.  If a robot can hear more than one broadcaster on the same channel, 
then it is jammed (although other robots may hear the communications just 
fine).  If a robot is broadcasting, then it is automatically self-jammed. 
Broadcasts are always true broadcasts; all robots that are within 
communications range will receive the message (barring jamming and link 
breakage).  It is up to individual robots to filter incoming messages as 
necessary.

Robots are free to move as they wish, even while communications are happening. 
Thus, it is possible for a link to be broken while communications are 
happening, or for a robot to stumble within range of a broadcasting robot.  In 
both cases, the robot will be aware that the channel is in use, but it will 
not receive a message as the link was not in an unbroken state the entire time 
the message was being broadcast.

There is always one special channel that has infinite bandwidth and zero 
communications range; robots must be coincident (basically physically 
connected) to use that channel.  This models ultra-short range communications 
between robots, like the 'communications' that would happen if you passed a 
tape or hard disk between robots.

All of this is to explore my dissertation problem; the intersection between 
data mules and mesh networks.  For those that are unfamiliar with the 
concepts, a robotic mesh network is basically a bunch of physically mobile 
wireless routers (flying, driving, crawling, etc.) that try to move around in 
such a way that every member of the network is always connected at all times, 
even as the members are moving around unpredictably themselves.  Data mules go 
the other way; they assume that all but one or two members of the network are 
immobile, and that the network is mostly partitioned.  The data mule will 
visit each component of the network graph and carry the data along to other 
components in what is hoped to be an efficient manner ('efficient' can be 
defined in many different ways). My goal is to develop heuristics that are 
usable when there are many uncooperative agents moving around that want to 
communicate with one another, and too few robots to maintain a full mesh 
network.  At least some of the robots will need to volunteer to be data mules 
at least part of the time.  Since I'm aiming at thousands to tens of thousands 
of robots at a time, I can't just build a bunch of robots and develop 
heuristics on the robots; I have to write a simulator.  If I can run Nanomsg 
on top of the network, then that will just make my dissertation even stronger.

So, my simulator does not provide the equivalent of TCP; just UDP.  Does 
Nanomsg require TCP to work correctly?  If so, I won't be able to adapt it 
without also creating a TCP stack on top of my simulator, which I already know 
would be problematic in these kinds of networks.  The Licklider transmission 
protocol (https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol) is 
the closest to a 'reliable' protocol that might work (still not tested on 
these networks as my simulator is incomplete).

Thanks,
Cem Karan

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Other related posts: