[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 19:12:32 +0000
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Monday, December 05, 2016 12:49 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [Non-DoD Source] Re: Modifications necessary to run
nanomsg on a simulator
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.)
At a brief glance, I think I could layer protocols on top of either one. At
the moment, I'm thinking it would be useful to layer the bundle protocol
(
https://tools.ietf.org/html/rfc5050) on top of the UDP layer (mostly because
the Licklider Transmission protocol,
https://tools.ietf.org/html/rfc5326, is ;
designed for UDP), which should give a stepping stone for better protocols in
extremely mutable network topologies like I'm interested in.
PLEASE keep me in the loop about the rewrite to make all this easier! I
suspect that I'm not the only person that would like to use nanomsg in this
manner, nor am I the only one that would be interested in extending it to
message-oriented protocols.
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.
I considered this, but I need some help. Basically, I need both of the
following:
- The ability to tie the rate that transmission occurs at to the simulated
time. That way each channel will have its own bandwidth, and nanomsg would
enforce this. I didn't see a method for doing this within nanomsg.
- The ability to break a connection while a transmission is happening. This
lets me simulate robots moving out of range of one another, or a bad actor
turning on its radio at a bad time.
If I can do both of those, then IPC would be ideal for me.
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.
Not a problem, I'm using Linux and OS X, and I have complete control over what
gets installed on the machines. In the worst case I'd wipe the machines and
install whatever OS I need to.
Thanks,
Cem Karan
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
Other related posts:
