A given aio has only one outstanding operation on it. A socket can have
many outstanding aios. Traffic will “probably” be handled in the order of
submission (generally the implementations use a FIFO to manage multiple
aios), but there is no guarantee of ordered delivery anywhere in nng.
The reason for this is that devices break streams, and if you have a
device, messages may be played on different streams, totally breaking the
order. Also different TCP flows (associated with a single socket) may have
different flow rates, resulting in misordered delivery.
For a given socket/application flow, you can order your message submissions
by using the same aio — the completion callback is used to queue up the
next message, and so forth. This does slow things down slightly, since you
introduce some inter-message latency that multiple parallel submissions
would not. It’s up to the app to decide which strategy works best for it.
(We do guarantee that messages are treated atomically though — a message
either arrives entirely and with all its bytes in order, or not at all.)
- Garrett
On Thu, Oct 26, 2017 at 6:36 AM Karan, Cem F CIV USARMY RDECOM ARL (US) <
cem.f.karan.civ@xxxxxxxx> wrote:
Nice! Quick question; are messages always sent in the same order as they
were queued up by the AIO interface?
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-----On Behalf Of Garrett D'Amore
From: nanomsg-bounce@xxxxxxxxxxxxx [mailto:nanomsg-bounce@xxxxxxxxxxxxx]
Sent: Wednesday, October 25, 2017 9:44 PMin nng
To: nanomsg@xxxxxxxxxxxxx
Subject: [Non-DoD Source] [nanomsg] async aio framework exposed to apps
callback scheme is removed (it was pretty horrible actually), and I’m
(This is only for nng, not available for legacy nanomsg.)
I just pushed nng bug #45. This changes the API. The old event
exposing an “aio” framework.completion callback and a user supplied argument for the callback.
The way aio’s work is that you allocate one (it’s like a handle) with a
later. You can also wait on them to be complete.
Then you can submit operations and get notified when they are complete
I figured that it was so useful to me that folks building other kinds of
E.g:
```
nng_aio *a;
void mycallback(void *);
void *myarg;
nng_aio_alloc(&a, mycallback, myarg);
nng_aio_set_timeout (a, 100);
nng_aio_set_message (a, msg);
nng_send_aio(s, a);
… asynchronously the message is sent, and the mycallback is executed.
… it can read the aio result via nng_aio_result (a);
Operations can also be canceled with nng_aio_cancel().
You can then do nng_aio_wait(a).
The details are for now in the nng.h header file.
Note that this is largely the same stuff I’m using *internally* in nng.
async apps could use it. For example, this could be used to integrateinto an event loop or drive state machine transitions, etc.
this was the major API change that I wanted to get through
Anyway, not sure how many of you might be poking at nng these days, but
before declaring a broader beta release. I’d appreciate folks bang awayat this.
before *formal* beta. Oh, and I need to write a lot more docs. :-)
I’m still going to try to get websocket and TLS support knocked out
Enjoy!
- Garrett
