Open supermihi opened 8 years ago
A dirty solution is to define MSGPACK_DEFAULT_API_VERSION=1
in project settings. That will effectively disable v2 namespace. It will compile and run fine.
Thanks, that fixes compilation. However, I'm not able to set up a connection to a crossbar.io server (see also #2). Question: Has anyone ever managed to use Autobahn|Cpp with VS 2015?
It compiles with VS2015, runs, connects and authenticates with crossbar.io 0.12.1. After fixing auth flow, I have not tried anything beyond authenticating and receiving a WELCOME. If you are running crossbar.io on windows, disable unix socket listener from crossbar config. I'll commit .sln and .vcxproj along with #46
Ah, nice! That's good news. If it can authenticate (eg https://github.com/crossbario/autobahn-cpp/blob/master/examples/wampcra.cpp), chances are high "it just works" (RPC and PubSub).
We should probably have a variant of above example that combines that with actually doing something. On the other hand: it's trivial to copy-paste code from the other examples.
Just noticed, part of my fix for wampcra got overwritten by most recent merge. break
missing for CHALLENGE again.
case message_type::CHALLENGE:
process_challenge(std::move(message));
+ break;
case message_type::AUTHENTICATE:
Thanks for your answers. I'm glad to hear that VS2015 appears to be supported now; however, I'm not able to get it running. I've done the following:
{ "type": "rawsocket", "endpoint": { "type": "tcp", "port": 8000 } }
̀int main(int argc, char** argv)
{
try {
const tcp::endpoint endpoint = tcp::endpoint(address::from_string("127.0.0.1"), 8000);
boost::asio::io_service io;
auto transport = make_shared<autobahn::wamp_tcp_transport>(io, endpoint);
auto session = make_shared<autobahn::wamp_session>(io, true);
transport->attach(static_pointer_cast<autobahn::wamp_transport_handler>(session));
boost::future<void> connect_future;
boost::future<void> start_future;
boost::future<void> join_future;
boost::future<void> call_future;
boost::future<void> leave_future;
boost::future<void> stop_future;
connect_future = transport->connect().then([&](boost::future<void> connected) {
try {
connected.get();
}
catch (const exception& e) {
cerr << e.what() << endl;
io.stop();
return;
}
cout << "transport connected" << endl;
start_future = session->start().then([&](boost::future<void> started) {
try {
started.get();
}
catch (const exception& e) {
cerr << e.what() << endl;
io.stop();
return;
}
cerr << "session started" << endl;
join_future = session->join("realm1").then([&](boost::future<uint64_t> joined) {
try {
cerr << "joined realm: " << joined.get() << endl;
}
catch (const exception& e) {
cerr << e.what() << endl;
io.stop();
return;
}
[...]
However, when I try to run this program, it says
starting io service
stopped io service
async_read: The system cannot find the file specified.
When debugging with VS2015, a lot of exceptions of type boost::exception_detail::clone_impl<std::system_error>
are thrown. In addition, the crossbar logs an autobahn.wamp.exception.TransportLost
.
Just an addition: With autobahn-python, I can connect to the router (using websocket, not rawsocket which doesn't appear to be supported by the python package) and call the example "add2" method without problems.
Sorry for the spam, I figured out that the problem was msgpack-python
not being installed on the crossbar side, while autobahn|cpp doesn't support json (does it?). After installing msgpack-python, everything works. To recap the steps necessary for others trying to get this running:
msgpack-python
on the crossbar server, and add a rawsocket transport in .crossbar\config.json
on a different port than the websocket transport, as described above.MSGPACK_DEFAULT_API_VERSION=1
preprocessor define to workaround the issue above (I still think this should be considered a bug, and using API version 2 is probably preferable?)I still think this should be considered a bug, and using API version 2 is probably preferable?
It works on gcc and clang, so if so, I'd consider it a VS bug. Ask MS to fix their compilers.
@supermihi
msgpack-python
: I have expanded the examples README https://github.com/crossbario/autobahn-cpp/tree/master/examples#run - installing via pip install crossbar[all]
will automatically install msgpack support as well. I also added links to other router implementations.Sorry l, forgot to mention msg pack on server side. I stepped on that rake also.
MSGPACK_DEFAULT_API_VERSION=1 is now defined in the headers for _WIN32
Regards,
Denis
On Feb 19, 2016, at 05:20, Michael Helmling notifications@github.com wrote:
Sorry for the spam, I figured out that the problem was msgpack-python not being installed on the crossbar side, while autobahn|cpp doesn't support json (does it?). After installing msgpack-python, everything works. To recap the steps necessary for others trying to get this running:
- Make sure to install msgpack-python on the crossbar server, and add a rawsocket transport in .crossbar\config.json on a different port than the websocket transport, as described above.
- Add the MSGPACK_DEFAULT_API_VERSION=1 preprocessor define to workaround the issue above (I still think this should be considered a bug, and using API version 2 is probably preferable?)
- Be sure to connect to the correct port of the rawsocket transport.
— Reply to this email directly or view it on GitHub.
I think this should be addressed by @DZabavchik recent contributions now. Closing (though I didn't test it .. lack of Windows).
Thanks a lot! I'll test on monday if it works out-of-the-box with VS2015 now but from what you mention I'm pretty sure it should.
There is a pre-build step that will complain about setting missing boost, msgpack and OpenSSL directories or updating project settings, it is pretty much self explanatory.
Regards,
Denis
On Feb 20, 2016, at 06:11, Michael Helmling notifications@github.com wrote:
Thanks a lot! I'll test on monday if it works out-of-the-box with VS2015 now but from what you mention I'm pretty sure it should.
— Reply to this email directly or view it on GitHub.
Since we probably don't want to be stuck on v1, I have submitted a defect to msgpack-c for this issue. I was able to provide a simple program demonstrating the issue and isolate it to a specific commit:
https://github.com/msgpack/msgpack-c/issues/442
I think that we should re-open this issue for the time being and revert hardcoding to v1 once msgpack is patched.
@davidchappelle agreed. reopened and changed title
Can we at least add add_compile_definitions(MSGPACK_DEFAULT_API_VERSION=1)
to current CMakeLists.txt? It's impossible to use autobahn-cpp-dev with debian 10 & 11 without fetching msgpack from Debian 9. Which is bad.
I think it'd be best to increase compatibility until msgpack v2 support is there. What do you think? @oberstet
If this sounds okay to you I'll create a PR.
@CanNuhlar yes indeed, sounds good!
this is better than current state, but we still should/want to move to msgpack 2 I guess, so pls leave comments, and keep this issue open or a new one ...
I am trying to use the autobahn-cpp library in a Visual Studio 2015 project. After including both msgpack-c and autobahn-cpp, I get the following compiler error. I have already enabled the preprocessor flags
MSGPACK_DISABLE_LEGACY_NIL
andMSGPACK_DISABLE_LEGACY_CONVERT
, as suggested in the msgpack-c readme for header-only mode. I'd appreciate any hints!