Remote PoW service to manipulate queued requests

[jserv]

At the moment, dcurl already provides preliminary FPGA acceleration with consistent APIs, which enable transparent switching among SIMD, OpenCL, and FPGA implementations. However, it is not straightforward to accelerate existing IRI instances with FPGA accelerations because of the interoperability. Thus, we shall provide a remote PoW service dedicated to queued requests as PoWbox does.

Expected output:

1. Use existing libraries, such as ZeroMQ and ProtocolBuffer, to marshal / serialize the PoW operations;
2. Provide client-side interface to access FPGA-accelerated machines. Cyclone V-based device is the preferable target;
3. Verify IRI or Tangle-Accelerator + dcurl integration with FPGA accelerations;

Reference:

1. PoWbox
2. diverDriver

[tylerw1369]

If you need help testing let me know I can on my nano. I can even allow you access to my nano if needed

[jserv]

However, I am a bit afraid that PoWbox might be too heavy to launch on devices powered by Cyclone V. powsrv just implements slim interface with protocol buffers.

[ajblane]

However, I am a bit afraid that PoWbox might be too heavy to launch on devices powered by Cyclone V. powsrv just implements slim interface with protocol buffers.

We only require RabbitMQ C client library on devices.

[ajblane]

As AMQP 0-9-1 Model, it can support patterns by setting exchange and route in AMQP 0-9-1 Model:

• Work queues
• Publish/subscribe
• Routing
• Request/reply (RPC)

IOTA's powbox uses AMQP 0-9-1 Model to implement a remote server to asynchronously do PoW and it deploys a kubernetes cluster including a client, a broker and a worker. For IRI with IOTA's powbox, an IRI uses a kubernetes cluster. Therefore, there is no problem for order number.

This PR, #117, it is inspired by IOTA's powbox. However, currently, if this PR is used in scenario of multi-clients, multi-workers and a broker, there is a problem of order number because multi-workers do not orderly publish results to the completed queue. For order number problem of the PR, I propose two methods to discuss them.

Method 1: A remote interface library for a client only can bind a message queue pair (incoming queue/ completed queue) in a broker and a worker.

Method 2: A remote interface library for a client only can bind a message queue pair (incoming queue/ completed queue) in a broker and multi-workers.

Both method 1 and 2, they need to be considered about how many message queue pairs a broker does not exceed the memory limitation.

On the other hand, method 2 needs to consider order number problem, the remote interface library needs to set message order when publishing the message into the broker and implement a buffer for order messages when consuming the completed buffer.

For easy implementations, I prefer to use the method 1.

[ajblane]

For the test method of this PR, #117, it currently is not easy for test. Therefore, we plan to provide RabbitMQ API hooks for testing dcurl worker and remote interface.

[ajblane]

For troubleshooting of using RabbitMQ APIs, we can refer to this issue, amqp_rpc_reply_t, amqp_status_enum and amqp_error_string2 to print information when trouble.

[jserv]

There is no real "easy implementation". Instead, it can be "straightforward" or "naive" from the perspective of architecture design.

[ajblane]

In this article, "Asynchronous Messaging Primer", basic message queuing patterns are listed below:

• One-way messaging
• Request/response messaging
• Broadcast messaging

For using ZeroMQ (zero broker/ zero latency ) to implement the request/response messaging pattern for FPGA boards as multi-workers, it needs to implement a broker. About how to implement it, we can refer to this article, "Robust Reliable Queuing (Paranoid Pirate Pattern)". However, we do not need to implement the broker by using RabbitMQ.

Moreover, whether we use ZeroMQ or RabbitMQ, we need to implement a solution for the order in which the client receives PoW result messages in scenario of multi-workers in the asynchronous messaging pattern. However, in the article "Robust Reliable Queuing (Paranoid Pirate Pattern)", the method of using synchronous request and asynchronous reply is used to guarantee that the client will never get an out-of-order reply.

By contrast, I prefer to use RabbitMQ. By the way, in a scenario for the broker and workers to run on a machine, we can refer to this article, "The Asynchronous Client/Server Pattern", to implement no broker by using ZeroMQ to reach lower latency. For using FPGA boards as workers, the scenario of no broker is not matched.

[ajblane]

Related to #127

[ajblane]

Related to #133

[ajblane]

Related to #137

[ajblane]

Related to #139

[ajblane]

Related to #146

[ajblane]

Related to #151

[ajblane]

Related to #152