oxen-io
/
oxen-mq
mirror of https://github.com/oxen-io/oxen-mq.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
oxen-mq/tests/test_commands.cpp

76 lines
2.2 KiB
C++
Raw Normal View History

Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
#include "common.h"
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
#include <future>
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
#include <lokimq/hex.h>
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
using namespace lokimq;
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
TEST_CASE("basic commands", "[commands]") {
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
std::string listen = "tcp://127.0.0.1:4567";
LokiMQ server{
"", "", // generate ephemeral keys
false, // not a service node
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
[](auto) { return ""; },
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
get_logger("S» ")
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
};
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
server.log_level(LogLevel::trace);
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
server.listen_curve(listen, [](auto /*ip*/, auto /*pk*/) { return Allow{AuthLevel::none, false}; });
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
std::atomic<int> hellos{0}, his{0};
server.add_category("public", Access{AuthLevel::none});
server.add_command("public", "hello", [&](Message& m) {
// On every 1st, 3rd, 5th, ... hello send back a hi
if (hellos++ % 2 == 0)
m.send_back("public.hi");
});
Fix truncated pubkey Fix bug from quorumnet transition; quorumnet set the user id to something like "S:abc..." or "C:abc..." to indicate SN or non-SN, but now that gets carried in a separate message property but the +2 on the copying position was still erroneously being used.
2020-02-17 03:42:03 +01:00
std::string client_pubkey;
server.add_command("public", "client.pubkey", [&](Message& m) {
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
client_pubkey = std::string{m.conn.pubkey()};
Fix truncated pubkey Fix bug from quorumnet transition; quorumnet set the user id to something like "S:abc..." or "C:abc..." to indicate SN or non-SN, but now that gets carried in a separate message property but the +2 on the copying position was still erroneously being used.
2020-02-17 03:42:03 +01:00
});
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
server.start();
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
LokiMQ client{
get_logger("C» ")
};
client.log_level(LogLevel::trace);
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
client.add_category("public", Access{AuthLevel::none});
client.add_command("public", "hi", [&](auto&) { his++; });
client.start();
std::atomic<bool> connected{false}, failed{false};
std::string pubkey;
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
auto c = client.connect_remote(listen,
[&](auto conn) { pubkey = conn.pubkey(); connected = true; },
[&](auto conn, string_view) { failed = true; },
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
server.get_pubkey());
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
int i;
for (i = 0; i < 5; i++) {
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
if (connected.load())
break;
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
std::this_thread::sleep_for(50ms);
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
}
REQUIRE( connected.load() );
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
REQUIRE( i <= 1 ); // should be fast
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
REQUIRE( !failed.load() );
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
REQUIRE( to_hex(pubkey) == to_hex(server.get_pubkey()) );
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
client.send(c, "public.hello");
client.send(c, "public.client.pubkey");
Fix truncated pubkey Fix bug from quorumnet transition; quorumnet set the user id to something like "S:abc..." or "C:abc..." to indicate SN or non-SN, but now that gets carried in a separate message property but the +2 on the copying position was still erroneously being used.
2020-02-17 03:42:03 +01:00
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
std::this_thread::sleep_for(50ms);
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
REQUIRE( hellos == 1 );
REQUIRE( his == 1 );
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
REQUIRE( to_hex(client_pubkey) == to_hex(client.get_pubkey()) );
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
for (int i = 0; i < 50; i++)
Added support for general (non-SN) communications The existing code was largely set up for SN-to-SN or client-to-SN communications, where messages can always get to the right place because we can always send by pubkey. This doesn't work when we want general communications with a random remote address. This commit overhauls the way loki-mq handles communication in a few important ways: - Listening instances no longer pass bind addresses into the constructor; instead they call `listen_curve()` or `listen_plain()` before invoking `start()`. - `listen_curve()` is equivalent to the existing bind support: it listens on a socket and accepts encrypted handshaked connections from anyone who already knows the server's public key. - `listen_plain()` is all new: it sets up a plain text listening socket over which random clients can connect and talk. End-points aren't verified, and it isn't encrypted, but if you don't know who you are talking to then encryption isn't doing anything anyway. - Connecting to a remote now connections in CURVE encryption or NULL (plain-text) encryption based on whether you provide a remote_pubkey. For CURVE, the connection will fail if the pubkey does not match. - `ConnectionID` objects are now returned when connecting to a remote address; this object is then passed in to send/request/etc. to direct the message. For SN communication, ConnectionID's can be created implicitly from SN pubkey strings, so the existing interface of `lmq.send(pubkey, ...)` will still work in most cases. - A ConnectionID is now passed to the ConnectSuccess and ConnectFailure callbacks. This can be used to uniquely identify which connection succeeded or failed, and can determine whether the remote is a service node (`.sn()`) and/or the pubkey (`.pubkey()`). (Obviously the service node status is only available when the client can do service node lookups, and the pubkey() is only non-empty for encrypted connections).
2020-02-28 05:16:43 +01:00
client.send(c, "public.hello");
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
Fix delayed proxy-scheduled batch jobs Batch jobs scheduled by the proxy thread itself were delayed to the next poll timeout (because nothing ever gets sent on a socket). Add a variable to bypass the next poll to handle this case.
2020-02-12 00:08:19 +01:00
std::this_thread::sleep_for(100ms);
Add request/reply abstraction This allows making RPC requests with a callback that gets called when the response comes back. The is essentially a wrapper around doing it yourself (i.e. by setting up a server-side "request" and client-side "reply" command where "request" responds with a "reply" command), but abstracted into lokimq itself as it is likely to be very useful when integrating client/server connections rather than peer-to-peer connections.
2020-02-11 07:30:07 +01:00
REQUIRE( hellos == 51 );
REQUIRE( his == 26 );
}