Well, my research focus is on ad-hoc mobile networks that are only
intermittently connected (think mesh radios, but where the radios are robots
that can physically carry messages long distances if they have to). In those
situations, you always need to decide what must get through, and what you can
let go of it doesn't make it through.
That said, I can see this being useful for applications like games or video,
where latency is more important than reliable delivery. In that case, you
might want to tag a frame with a maximum latency metric; if it's older than
that, nodes along the way are free to drop it.
<Wishful thinking>
I guess what I want is something like LTP + BEEP + SCTP; you have multiple
channels, each of which has been preconfigured with some set of parameters
(red/green, latency metric, whatever), and you push messages into the buffers
for each channel. Then nng handles dealing with fairness, dropping stuff,
etc., to multiplex the channels onto the transport medium. Oh, and since I'm
putting together a wish list, I want nng to tell the node a message is on about
the fact that it is about to drop the message (e.g, A wants to deliver to C via
B, but B can't find a route to C; in that case, nng calls some callback on B to
tell it that it is about to drop the message).
</Wishful thinking>
I know that all of the above is out of the scope of nng, but that is the way
I'd like to see it extended.
Thanks,
Cem Karan
---
Other than quoted laws, regulations or officially published policies, the views
expressed herein are not intended to be used as an authoritative state of the
law nor do they reflect official positions of the U.S. Army, Department of
Defense or U.S. Government.
-----Original Message-----
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Garrett D'Amore
Sent: Tuesday, January 02, 2018 1:35 PM
To: nanomsg@xxxxxxxxxxxxx
Subject: [nanomsg] Re: [nanomsg] RE: [Non-DoD Source] [nanomsg] nng version
0.2.0 — Happy New Year!
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.
________________________________
I can imagine extending nng to run over LTP. I suppose you’d probably make
most of the transports “green”, but REQ/REP frames would
be “red”.
The thing is that nanomsg and nng already have this separation, at the layer
above. This mapping may lead to some interesting
capabilities on top of a transport that can express these needs separately —
but it would take some effort to experiment and build such a
thing. I have no experience or knowledge of LTP before this. I guess I
haven’t needed to communicate over a deep space network before,
but this is kind of cool.
- Garrett
On Tue, Jan 2, 2018 at 10:12 AM Karan, Cem F CIV USARMY RDECOM ARL (US)
<cem.f.karan.civ@xxxxxxxx < Caution-
mailto:cem.f.karan.civ@xxxxxxxx ;> > wrote:
Hi Garrett, a quick question about the extensibility of nng; is it
possible to extend it to support red and green parts similar to the
Licklider Transmission Protocol (see towards the end of the Design section
for definitions of red and green: Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol#Design) <
Caution-
https://en.wikipedia.org/wiki/Licklider_Transmission_Protocol#Design)? > ?
I can see a lot of practical use cases where only portions of a
stream need to be guaranteed delivery, but I can also see how this is not a
current focus of nng. I just want to know if the current
framework is flexible enough to support it.
Thanks,
Cem Karan
________________________________
From: nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> [nanomsg-bounce@xxxxxxxxxxxxx <
Caution-mailto:nanomsg-bounce@xxxxxxxxxxxxx ;> ] on behalf of Garrett D'Amore
[garrett@xxxxxxxxxx < Caution-
mailto:garrett@xxxxxxxxxx ;> ]
Sent: Saturday, December 30, 2017 10:17 PM
To: nanomsg@xxxxxxxxxxxxx < Caution-mailto:nanomsg@xxxxxxxxxxxxx ;>
Subject: [Non-DoD Source] [nanomsg] nng version 0.2.0 — Happy New Year!
Happy New Year (a little early)!
In the spirit of celebration of the year 2018, I’m pleased to announce
that nng — that is nanomsg-next-gen — version 0.2.0 is now
released.
For those of you who have not been following, nng represents my effort
to completely redesign a modern nanomsg framework that can grow to
support new technologies and capabilities, and succeed in
ways that nanomsg itself was unable.
This is a pre-release, but I consider it “beta" level of stability.
It still has some maturing to do, and some important functionality
is missing, but already it is quite usable. Barring the lack of adequate
documentation and certain performance elements, I believe this
version to be superior to the official nanomsg in most regards.
This release adds secure websocket support, using the wss:// scheme,
which means it is now possible to use TLS v1.2 and
websocket together. It also supports multiple sockets using the same TCP
port when using either wss:// or ws:// schemes — the server
will discriminate based on the full URL (or in some cases, the value of Host:)
In the coming weeks and months, expect much more complete
documentation, performance improvements, observability
improvements (actual statistics!), and some interesting new capabilities for
web applications and people wanting to build gateways
between the web and nanomsg applications.
For folks that want to participate and help, give me a shout. There
are still lots of ways to assist, and things to do.
— Garrett
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
