CppWAMP v0.10.0 Released

[Emile Cormier]

Hi Everyone,

Version 0.10.0 of the CppWAMP C++ WAMP client library has been released.

Some of new features:

• Callback functions, yield_context, use_awaitable, and use_future now supported as completion tokens.
• C++20 coroutines now supported
• Migrated from AsyncResult to new ErrorOr class which better emulates the proposed std::expected.
• Added Session overloads with the ThreadSafe tag type which can be called concurrently by multiple threads.
• Users can bind custom executors to their handlers and Session will use them when executing those handlers.
• Boost.Asio cancellation slot support for Session::call.

I'm now starting work on these upcoming features:

• Polymorphic codecs and transports (instead of current template mess)
• Embeddable router

The enthusiasm towards WAMP seems to have waned over the years (I hope I'm wrong about that). Out of curiosity, what other technology is being using instead?

Cheers,

Emile Cormier

[Tobias Oberstein]

Hi Emile,

awesome! thanks for sharing your work!

Am 14.08.22 um 02:12 schrieb Emile Cormier:
> Hi Everyone,
>
> Version 0.10.0 of the CppWAMP <https://github.com/ecorm/cppwamp> C++

> WAMP client library has been released.
>
> Some of new features:
>

> * Callback functions, yield_context, use_awaitable, and use_future now
> supported as completion tokens.
> * C++20 coroutines now supported
> * Migrated from AsyncResult to new ErrorOr class which better emulates
> the proposed std::expected.
> * Added Session overloads with the ThreadSafe tag type which can be

> called concurrently by multiple threads.

> * Users can bind custom executors to their handlers and Session will

> use them when executing those handlers.

> * Boost.Asio cancellation slot support for Session::call.

very cool, also supporting C++20 coroutines: +1

looking through the examples with the various different approaches, one
thing I am wondering: do you have guidelines/tips for users _which_
approach to use?

say, I want to get started with "the simplest" example demonstrating all
4 WAMP actions, and say I have a modern/recent g++/clang.

which example should I clone to start with?

there seems to be 2 main approaches offered which are outlined in

https://github.com/ecorm/cppwamp#usage-examples-using-stackful-coroutines

https://github.com/ecorm/cppwamp#usage-examples-using-asynchronous-callbacks

right? I think it would be nice to have a short description of each
approach, and a comparison/guide of both added, and move this right to
the top after "features" in the readme. probably even adding the same
clients with 4 actions using javascript/browser. just to show and
convince right in the beginning ..

>
> I'm now starting work on these upcoming features:
>

> * Polymorphic codecs and transports (instead of current template mess)

not sure, what is "polymorphic" codecs?

> * Embeddable router

have you decided about the general design yet, such as "sans-IO" or
integrated with a specific loop/reactor?

>
> The enthusiasm towards WAMP seems to have waned over the years (I hope
> I'm wrong about that). Out of curiosity, what other technology is being
> using instead?

fwiw, I'd also be interested in this!

from what I see, eg in IoT, the more modern/advanced users are often
using MQTT and REST. hack sth together on top to make a specific app
with a concrete mix of services/components work. very pragmatic / adhoc.

eg there are AT-command modem chips (eg ESP32) with a MQTT client
built-in you can talk to from your main MCU via UART ..

Cheers,
/Tobias



>
> Cheers,
> Emile Cormier
>
> --
> You received this message because you are subscribed to the Google
> Groups "WAMP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to wampws+un...@googlegroups.com
> <mailto:wampws+un...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/wampws/21aaa30b-c430-49da-91b4-ee073141402bn%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/21aaa30b-c430-49da-91b4-ee073141402bn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Emile Cormier]

On Sunday, August 14, 2022 at 9:55:53 AM UTC-3 Tobias wrote:

looking through the examples with the various different approaches, one
thing I am wondering: do you have guidelines/tips for users _which_
approach to use?

say, I want to get started with "the simplest" example demonstrating all
4 WAMP actions, and say I have a modern/recent g++/clang.

which example should I clone to start with?

The examples with stackful couroutines are the simplest to follow, where the asynchronous logic is written in a synchronous manner. examples/chat/main.cpp demonstrates pub/sub/register/call in the same program using stackful coroutines. examples/timeclient/main.cpp and examples/timeservice/main.cpp also demonstrate the 4 WAMP actions together, with one side providing services and the other consuming them.

 

there seems to be 2 main approaches offered which are outlined in

https://github.com/ecorm/cppwamp#usage-examples-using-stackful-coroutines

https://github.com/ecorm/cppwamp#usage-examples-using-asynchronous-callbacks

right? I think it would be nice to have a short description of each
approach, and a comparison/guide of both added, and move this right to
the top after "features" in the readme. probably even adding the same
clients with 4 actions using javascript/browser. just to show and
convince right in the beginning ..

Thank you for the suggestion. I guess I take it for granted that users are already familiar with Boost.Asio and it's various styles of asynchronous programming. There are two more main approaches: stackless coroutines and C++20 coroutines (which are also stackless). I focused on stackful coroutines and async callbacks in the README because those are the two approaches I happen to use in my work and am most familiar with.

 

not sure, what is "polymorphic" codecs?

There will be a new AnyCodec type that performs type-erasure of concrete codecs such as JsonCodec or CborCodec. The actual encoding/decoding operations will be invoked via virtual function dispatch. This will eliminate a lot of reliance on templates that make the implementation more complex, at the cost of virtual function overhead (which is probably insignificant anyway).

 

> * Embeddable router

have you decided about the general design yet, such as "sans-IO" or
integrated with a specific loop/reactor?

It'll be integrated with Boost.Asio and will leverage the existing CppWAMP code as much as possible. The same library will provide both client and router implementations. I'm not familiar with this "sans-IO" that you speak of; I'll check it out.

 

from what I see, eg in IoT, the more modern/advanced users are often
using MQTT and REST. hack sth together on top to make a specific app
with a concrete mix of services/components work. very pragmatic / adhoc.

Well, what drew me to WAMP in the first place was pub/sub and requests (i.e. RPCs) being integrated and taking place over the same transport.

 

Cheers,

Emile

[Tobias Oberstein]

> have you decided about the general design yet, such as "sans-IO" or
> integrated with a specific loop/reactor?
>
>
> It'll be integrated with Boost.Asio and will leverage the existing
> CppWAMP code as much as possible. The same library will provide both

Sounds cool! For anything *nix, Android or Windows or similar,
Boost.Asio is no problem.

Probably asking since I'm still contemplating bringing WAMP to deeply
embedded systems, where there is neither virtual memory, nor (often) any
kind of dynamic memory. Or standard library (neither C nor C++).
Anyways, that's a different world.

> client and router implementations. I'm not familiar with this "sans-IO"
> that you speak of; I'll check it out.

sure, it's just a general design pattern for networking stuff. fwiw,
here are 2 pointers:

https://www.youtube.com/watch?v=7cC3_jGwl_U
https://sans-io.readthedocs.io/

>
> from what I see, eg in IoT, the more modern/advanced users are often
> using MQTT and REST. hack sth together on top to make a specific app
> with a concrete mix of services/components work. very pragmatic /
> adhoc.
>
>
> Well, what drew me to WAMP in the first place was pub/sub and requests
> (i.e. RPCs) being integrated and taking place over the same transport.

yes, agreed;) I would add: MQTT+REST hacks will usually tie the app to
details of the network infrastructure. Well. I don't want to go there,
and since I haven't found anything better, I'll keep using it when I can ..

[Emile Cormier]

On Sunday, August 14, 2022 at 6:47:32 PM UTC-3 Tobias wrote:

Probably asking since I'm still contemplating bringing WAMP to deeply
embedded systems, where there is neither virtual memory, nor (often) any
kind of dynamic memory. Or standard library (neither C nor C++).
Anyways, that's a different world.

One issue with WAMP is the dynamic nature of message options, which can be quite verbose. It would better for microcontrollers if such options were bit fields, an array of bytes, or an array of very short "code" strings. The tree-like and verbose nature of WAMP message options is great for extensibility and debugging wire captures, but no so much for keeping the message overhead small for microcontrollers.

[Tobias Oberstein]

Am 15.08.22 um 00:38 schrieb Emile Cormier:

if you skip custom options, then this is supported in WAMP Flatbuffers
serialization, eg

https://github.com/crossbario/autobahn-python/blob/d337467714ca9737d614432b2c0dd7ab1373a3f7/autobahn/wamp/flatbuffers/pubsub.fbs#L69

next issue are any used IDs itself, which are of variable length, eg

topic: string (required, uri);
exclude_authid: [string] (principal);

both are under application control. as is the actual payload (args/kwargs).

what is needed is planning in the app, and limit eg URI length and such.
this can then be enforced in the router.

above can be done in static memory. eg the MCU can reserve N slots of
"WAMP actions" (such as a call or an event) with a max mem per slot

the resulting limits are:

- there can only be N concurrently active (unprocessed calls,
invocation, events)
- issuing more actions results in an error, or in dropping incoming data
- the per-action size (eg call args/kwargs + options + ..) is limited to M
- the whole mem usage is N x M

>
> --
> You received this message because you are subscribed to the Google
> Groups "WAMP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to wampws+un...@googlegroups.com
> <mailto:wampws+un...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/wampws/16d7a484-918c-4755-939a-d5e7ec016f11n%40googlegroups.com
> <https://groups.google.com/d/msgid/wampws/16d7a484-918c-4755-939a-d5e7ec016f11n%40googlegroups.com?utm_medium=email&utm_source=footer>.