Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement basic WAMP router classes #33

Open
ecorm opened this issue Apr 6, 2015 · 8 comments
Open

Implement basic WAMP router classes #33

ecorm opened this issue Apr 6, 2015 · 8 comments
Assignees
Milestone

Comments

@ecorm
Copy link
Owner

ecorm commented Apr 6, 2015

Implement a RouterSession class that derives from internal::Session and implements the broker/dealer roles according to the basic spec. The RouterSession instances would share information with a common RouterRealm class.

Reading configuration parameters and providing a meta-API should be provided in separate router application classes.

@ecorm ecorm changed the title Implement basic WAMP router class Implement basic WAMP router classes Apr 7, 2015
@davidchappelle
Copy link

I have invested a significant amount of time implementing a c++ wamp router. You might want to sync up with me and have a look at it before getting too far down this path.

@ecorm
Copy link
Owner Author

ecorm commented Apr 13, 2015

@davidchappelle , thanks for reaching out! Is your router implementation hosted somewhere? Does it have a heavy dependency on boost::future and boost::any?

We might want to take a cue from Crossbar.io + Autobahn|JS, and make the C++ router its own project, with cppwamp as a submodules dependency.

Also, please be advised that I've overhauled the CppWAMP API to make better use of fluent API techniques. I humbly think the API is much cleaner now as a result, not to mention more extensible. I just need to update the documentation and tutorials, and will soon make a commit to the GitHub repo.

@davidchappelle
Copy link

@ecorm I haven't yet posted the router implementation publicly. Shouldn't be more than a few weeks out from doing so. I haven't added any client code at all to the project so it is purely a router implementation. I do not use boost::future or boost::any anywhere. I actually just used msgpack-c as a basis for variant types since that is essentially what it is anyways. It has support for websockets (via websocketpp) as well as rawsockets. Pretty much all of the basic profile is implemented and slowly chipping away at the advanced profile pieces.

@ecorm
Copy link
Owner Author

ecorm commented Apr 13, 2015

I won't be starting on a router implementation anytime soon. Our embedded system is powerful enough to handle Crossbar.io, so we can get by using it. In the long term, though, it would be preferable if we could use a natively-compiled router that doesn't have huge library and runtime dependencies.

@davidchappelle
Copy link

Ok perfect. I will notify the wamp implementation list as soon as I have something ready. FWIW, the c++ router is pretty lightweight and is likely more suitable for embedded applications. Current footprint of the binary is:

1.3MB unstripped
0.9 MB stripped

Dependencies are minimal and include:

boost asio
boost regex
boost system
websocketpp (header only)
msgpack-c (header only)
rapidjson (header only)

@estan
Copy link
Contributor

estan commented May 9, 2015

bump, are things moving @davidchappelle ? You mentioned on the list a while ago that it was very close. I'd love to try it out :)

@ecorm
Copy link
Owner Author

ecorm commented Nov 12, 2015

Given the availability and active development of the Bonefish router, I will not be persuing router functionality for CppWAMP. CppWAMP will remain a client-only library in the foreseeable future.

@ecorm ecorm closed this as completed Nov 12, 2015
@ecorm
Copy link
Owner Author

ecorm commented Aug 13, 2022

I'm now committed to adding router functionality to CppWAMP. In the parent project using CppWAMP, we wish to migrate to Buildroot where it's not possible to deploy recent versions of Crossbar. The currently available C++ routers don't support the features we need.

@ecorm ecorm reopened this Aug 13, 2022
@ecorm ecorm self-assigned this Sep 1, 2022
@ecorm ecorm added this to the 1.0.0 milestone Sep 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants