This is a lot of work, i think it might have been a good idea to actually do that over 2 PRs. but it's too late now:
The first changes, are regarding some refactoring of the entire code base to separate different operational parts the app was split into multiple layers:
Low level connection (the socket layer)
Responsible for authentication with the relay
Maintaining a constant connection, reconnects if needed
Protocol layer
Sends/Receives envelops over the low level socket
Signing and e2e encryption so higher layers don't need to worry about that
Handling of protocol errors (answers if got invalid message for example)
App layer, this is what implements the logic of handling user requests, build proper messages and dispatching responses back to the caller. This is implemented over multiple parts which include
Postman, the postman is responsible for sending messages only BUT it can track the sent messages (with tracker) which then can be consulted when a response is received to dispatch the incoming message. Dispatching then can either be directly to a redis channel (when the caller was a client that uses the json/redis interface default behavior) or can be routed internally to a plugin if the request was initiated with a pluing
All this work was intended to allow custom plugins. Please read plugins docs for more information. But in a nutshell a plugin allows the rmb-peer to handle some requests itself without the need for a running local service. A plugin can be very simple as in if u get this request send this response, or more complex scenarios where the plugin needs to have 2 way negotiations.
Included in the PR a file upload plugin (please read the docs on how this operate).
Missing
Currently file upload does not handle timeouts in case either of the peers is not responding
Do we need to ask for missing parts if any ?
Speed negotiations so if relay decided to drop some messages for exceeding the max rate that the upload does not get corrupted.
The plugin and the code is taking those points above in consideration even if not implemented yet
This is a lot of work, i think it might have been a good idea to actually do that over 2 PRs. but it's too late now:
The first changes, are regarding some refactoring of the entire code base to separate different operational parts the app was split into multiple layers:
All this work was intended to allow custom plugins. Please read plugins docs for more information. But in a nutshell a plugin allows the rmb-peer to handle some requests itself without the need for a running local service. A plugin can be very simple as in if u get this request send this response, or more complex scenarios where the plugin needs to have 2 way negotiations.
Included in the PR a
file uploadplugin (please read the docs on how this operate).Missing
timeoutsin case either of the peers is not respondingThe plugin and the code is taking those points above in consideration even if not implemented yet