Today, nanomsg does require full TCP, or a stream oriented channel.
Technically it is possible to make a message oriented protocol (one that is
lossy and perhaps does not have perfect delivery) based transport, but it
means diving pretty deep into nanomsg’s guts to make this happen. I’m in
the process of rewriting nanomsg to make this easier. There are two RFCs
in the nanomsg repo for message oriented transports - one for ZeroTier and
one for UDP. You can have a look at those. (Note that I’m thinking of yet
one more refinement to the UDP transport to provide improved protection
against message corruption — UDP’s simple CRC is a bit less robust than I’d
really like — but I’ve not decided yet whether to do this or not, since the
folks using UDP are usually going to be doing so in performance critical
situations.)
Now, having said that, if you’re implementing a true simulator, in a single
process, you could use the inproc transport to do in-process
communication. You can also use IPC which might be easier to implement in
a multi-process simulator.
Note that if you’re platform is not compliant with POSIX, or Windows, you
are going to have other problems porting nanomsg, as we require certain
primitives and functions be supplied. There is an operating system porting
layer available, but it isn’t documented at the moment.
On Mon, Dec 5, 2016 at 8:02 AM, Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:
-----Original Message-----On
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Behalf Of SGSeven Algebrafwrite
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
it yourself. Which language do you use for your simulator?many
Generally speaking nanomsg can be used on all kinds of platforms with
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
