2020-02-12 00:08:19 +01:00
|
|
|
#include "common.h"
|
2020-02-28 05:16:43 +01:00
|
|
|
#include <lokimq/hex.h>
|
2020-02-11 07:30:07 +01:00
|
|
|
|
|
|
|
using namespace lokimq;
|
|
|
|
|
2020-02-12 00:08:19 +01:00
|
|
|
TEST_CASE("basic requests", "[requests]") {
|
2020-10-15 21:13:37 +02:00
|
|
|
std::string listen = random_localhost();
|
2020-02-11 07:30:07 +01:00
|
|
|
LokiMQ server{
|
|
|
|
"", "", // generate ephemeral keys
|
|
|
|
false, // not a service node
|
2020-02-28 05:16:43 +01:00
|
|
|
[](auto) { return ""; },
|
2020-02-11 07:30:07 +01:00
|
|
|
};
|
2020-02-28 05:16:43 +01:00
|
|
|
server.listen_curve(listen);
|
2020-02-11 07:30:07 +01:00
|
|
|
|
|
|
|
std::atomic<int> hellos{0}, his{0};
|
|
|
|
|
|
|
|
server.add_category("public", Access{AuthLevel::none});
|
|
|
|
server.add_request_command("public", "hello", [&](Message& m) {
|
|
|
|
m.send_reply("123");
|
|
|
|
});
|
|
|
|
server.start();
|
|
|
|
|
|
|
|
LokiMQ client(
|
|
|
|
[](LogLevel, const char* file, int line, std::string msg) { std::cerr << file << ":" << line << " --C-- " << msg << "\n"; }
|
|
|
|
);
|
|
|
|
//client.log_level(LogLevel::trace);
|
|
|
|
|
|
|
|
client.start();
|
|
|
|
|
|
|
|
std::atomic<bool> connected{false}, failed{false};
|
|
|
|
std::string pubkey;
|
|
|
|
|
2020-06-29 20:39:11 +02:00
|
|
|
auto c = client.connect_remote(address{listen, server.get_pubkey()},
|
2020-02-28 05:16:43 +01:00
|
|
|
[&](auto conn) { pubkey = conn.pubkey(); connected = true; },
|
2020-06-29 20:39:11 +02:00
|
|
|
[&](auto, auto) { failed = true; });
|
2020-02-11 07:30:07 +01:00
|
|
|
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
wait_for([&] { return connected || failed; });
|
2020-03-21 15:27:01 +01:00
|
|
|
{
|
|
|
|
auto lock = catch_lock();
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
REQUIRE( connected );
|
|
|
|
REQUIRE_FALSE( failed );
|
2020-03-21 15:27:01 +01:00
|
|
|
REQUIRE( to_hex(pubkey) == to_hex(server.get_pubkey()) );
|
|
|
|
}
|
2020-02-11 07:30:07 +01:00
|
|
|
|
|
|
|
std::atomic<bool> got_reply{false};
|
|
|
|
bool success;
|
|
|
|
std::vector<std::string> data;
|
2020-02-28 05:16:43 +01:00
|
|
|
client.request(c, "public.hello", [&](bool ok, std::vector<std::string> data_) {
|
|
|
|
got_reply = true;
|
|
|
|
success = ok;
|
|
|
|
data = std::move(data_);
|
|
|
|
});
|
|
|
|
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
reply_sleep();
|
|
|
|
{
|
|
|
|
auto lock = catch_lock();
|
|
|
|
REQUIRE( got_reply.load() );
|
|
|
|
REQUIRE( success );
|
|
|
|
REQUIRE( data == std::vector<std::string>{{"123"}} );
|
|
|
|
}
|
2020-02-28 05:16:43 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
TEST_CASE("request from server to client", "[requests]") {
|
2020-10-15 21:13:37 +02:00
|
|
|
std::string listen = random_localhost();
|
2020-02-28 05:16:43 +01:00
|
|
|
LokiMQ server{
|
|
|
|
"", "", // generate ephemeral keys
|
|
|
|
false, // not a service node
|
|
|
|
[](auto) { return ""; },
|
|
|
|
};
|
|
|
|
server.listen_curve(listen);
|
|
|
|
|
|
|
|
std::atomic<int> hellos{0}, his{0};
|
|
|
|
|
|
|
|
server.add_category("public", Access{AuthLevel::none});
|
|
|
|
server.add_request_command("public", "hello", [&](Message& m) {
|
|
|
|
m.send_reply("123");
|
|
|
|
});
|
|
|
|
server.start();
|
|
|
|
|
|
|
|
LokiMQ client(
|
|
|
|
[](LogLevel, const char* file, int line, std::string msg) { std::cerr << file << ":" << line << " --C-- " << msg << "\n"; }
|
|
|
|
);
|
|
|
|
//client.log_level(LogLevel::trace);
|
|
|
|
|
|
|
|
client.start();
|
|
|
|
|
|
|
|
std::atomic<bool> connected{false}, failed{false};
|
|
|
|
std::string pubkey;
|
|
|
|
|
2020-06-29 20:39:11 +02:00
|
|
|
auto c = client.connect_remote(address{listen, server.get_pubkey()},
|
2020-02-28 05:16:43 +01:00
|
|
|
[&](auto conn) { pubkey = conn.pubkey(); connected = true; },
|
2020-06-29 20:39:11 +02:00
|
|
|
[&](auto, auto) { failed = true; });
|
2020-02-28 05:16:43 +01:00
|
|
|
|
|
|
|
int i;
|
|
|
|
for (i = 0; i < 5; i++) {
|
|
|
|
if (connected.load())
|
|
|
|
break;
|
|
|
|
std::this_thread::sleep_for(50ms);
|
|
|
|
}
|
2020-03-21 15:27:01 +01:00
|
|
|
{
|
|
|
|
auto lock = catch_lock();
|
|
|
|
REQUIRE( connected.load() );
|
|
|
|
REQUIRE( !failed.load() );
|
|
|
|
REQUIRE( i <= 1 );
|
|
|
|
REQUIRE( to_hex(pubkey) == to_hex(server.get_pubkey()) );
|
|
|
|
}
|
2020-02-28 05:16:43 +01:00
|
|
|
|
|
|
|
std::atomic<bool> got_reply{false};
|
|
|
|
bool success;
|
|
|
|
std::vector<std::string> data;
|
|
|
|
client.request(c, "public.hello", [&](bool ok, std::vector<std::string> data_) {
|
2020-02-11 07:30:07 +01:00
|
|
|
got_reply = true;
|
|
|
|
success = ok;
|
|
|
|
data = std::move(data_);
|
|
|
|
});
|
|
|
|
|
2020-02-12 00:08:19 +01:00
|
|
|
std::this_thread::sleep_for(50ms);
|
2020-03-21 15:27:01 +01:00
|
|
|
{
|
|
|
|
auto lock = catch_lock();
|
|
|
|
REQUIRE( got_reply.load() );
|
|
|
|
REQUIRE( success );
|
|
|
|
REQUIRE( data == std::vector<std::string>{{"123"}} );
|
|
|
|
}
|
2020-02-11 07:30:07 +01:00
|
|
|
}
|
2020-03-24 02:30:53 +01:00
|
|
|
|
|
|
|
TEST_CASE("request timeouts", "[requests][timeout]") {
|
2020-10-15 21:13:37 +02:00
|
|
|
std::string listen = random_localhost();
|
2020-03-24 02:30:53 +01:00
|
|
|
LokiMQ server{
|
|
|
|
"", "", // generate ephemeral keys
|
|
|
|
false, // not a service node
|
|
|
|
[](auto) { return ""; },
|
|
|
|
};
|
|
|
|
server.listen_curve(listen);
|
|
|
|
|
|
|
|
std::atomic<int> hellos{0}, his{0};
|
|
|
|
|
|
|
|
server.add_category("public", Access{AuthLevel::none});
|
|
|
|
server.add_request_command("public", "blackhole", [&](Message& m) { /* doesn't reply */ });
|
|
|
|
server.start();
|
|
|
|
|
|
|
|
LokiMQ client(
|
|
|
|
[](LogLevel, const char* file, int line, std::string msg) { std::cerr << file << ":" << line << " --C-- " << msg << "\n"; }
|
|
|
|
);
|
|
|
|
//client.log_level(LogLevel::trace);
|
|
|
|
|
|
|
|
client.CONN_CHECK_INTERVAL = 10ms; // impatience (don't set this low in production code)
|
|
|
|
client.start();
|
|
|
|
|
|
|
|
std::atomic<bool> connected{false}, failed{false};
|
|
|
|
std::string pubkey;
|
|
|
|
|
2020-06-29 20:39:11 +02:00
|
|
|
auto c = client.connect_remote(address{listen, server.get_pubkey()},
|
2020-03-24 02:30:53 +01:00
|
|
|
[&](auto conn) { pubkey = conn.pubkey(); connected = true; },
|
2020-06-29 20:39:11 +02:00
|
|
|
[&](auto, auto) { failed = true; });
|
2020-03-24 02:30:53 +01:00
|
|
|
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
wait_for([&] { return connected || failed; });
|
|
|
|
|
|
|
|
REQUIRE( connected );
|
|
|
|
REQUIRE_FALSE( failed );
|
2020-03-24 02:30:53 +01:00
|
|
|
REQUIRE( to_hex(pubkey) == to_hex(server.get_pubkey()) );
|
|
|
|
|
|
|
|
std::atomic<bool> got_triggered{false};
|
|
|
|
bool success;
|
|
|
|
std::vector<std::string> data;
|
|
|
|
client.request(c, "public.blackhole", [&](bool ok, std::vector<std::string> data_) {
|
|
|
|
got_triggered = true;
|
|
|
|
success = ok;
|
|
|
|
data = std::move(data_);
|
|
|
|
},
|
2020-05-20 03:41:33 +02:00
|
|
|
lokimq::send_option::request_timeout{10ms}
|
2020-03-24 02:30:53 +01:00
|
|
|
);
|
|
|
|
|
|
|
|
std::atomic<bool> got_triggered2{false};
|
|
|
|
client.request(c, "public.blackhole", [&](bool ok, std::vector<std::string> data_) {
|
|
|
|
got_triggered = true;
|
|
|
|
success = ok;
|
|
|
|
data = std::move(data_);
|
|
|
|
},
|
2020-05-20 03:41:33 +02:00
|
|
|
lokimq::send_option::request_timeout{200ms}
|
2020-03-24 02:30:53 +01:00
|
|
|
);
|
|
|
|
|
2020-05-20 03:41:33 +02:00
|
|
|
std::this_thread::sleep_for(100ms);
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
REQUIRE( got_triggered );
|
|
|
|
REQUIRE_FALSE( got_triggered2 );
|
2020-03-24 02:30:53 +01:00
|
|
|
REQUIRE_FALSE( success );
|
1.1.0: invocation-time SN auth; failure responses
This replaces the recognition of SN status to be checked per-command
invocation rather than on connection. As this breaks the API quite
substantially, though doesn't really affect the functionality, it seems
suitable to bump the minor version.
This requires a fundamental shift in how the calling application tells
LokiMQ about service nodes: rather than using a callback invoked on
connection, the application now has to call set_active_sns() (or the
more efficient update_active_sns(), if changes are readily available) to
update the list whenever it changes. LokiMQ then keeps this list
internally and uses it when determining whether to invoke.
This release also brings better request responses on errors: when a
request fails, the data argument will now be set to the failure reason,
one of:
- TIMEOUT
- UNKNOWNCOMMAND
- NOT_A_SERVICE_NODE (the remote isn't running in SN mode)
- FORBIDDEN (auth level denies the request)
- FORBIDDEN_SN (SN required and the remote doesn't see us as a SN)
Some of these (UNKNOWNCOMMAND, NOT_A_SERVICE_NODE, FORBIDDEN) were
already sent by remotes, but there was no connection to a request and so
they would log a warning, but the request would have to time out.
These errors (minus TIMEOUT, plus NO_REPLY_TAG signalling that a command
is a request but didn't include a reply tag) are also sent in response
to regular commands, but they simply result in a log warning showing the
error type and the command that caused the failure when received.
2020-04-13 00:57:19 +02:00
|
|
|
REQUIRE( data == std::vector<std::string>{{"TIMEOUT"}} );
|
2020-03-24 02:30:53 +01:00
|
|
|
|
|
|
|
}
|