the proxy endpoints on the RMB server

[sameh-farouk]

this server implements only 2 end-points as explained above
/rmb-remote
/rmb-reply

for the RMB HTTP server, I don't see the two extra endpoints that used to be there to handle the proxy flow. is there any alternative suggestion for that? if that is not intended it would be useful to show the proxy flow in the doc too.

[muhamadazmy]

Can you explain in more details what the proxy should do. We then can extend the design or add the extra end points if needed to be done separately

[sameh-farouk]

In the end of the readme.md here
https://github.com/threefoldtech/rmb_go

There are two extra endpoints mentioned

/zbus-cmd
/zbus-result

They Serve the purpose of sending messages to remote RMB directly via HTTP client without the need to running either Redis or RMB locally, messages would be routed via a proxy(rmb-proxy) that runs an instance of RMB to the remote destination.

[OmarElawady]

Just documenting that the new proxy scheme is not backward compatible between the proxy and the rmb. It can be backward compatible between the client and the proxy if it's implemented as such.

The old proxy was based on poll approach between the client and the proxy. And the proxy forwarded the message as is to the rmb. The rmb has a special handling in that during the reply, it doesn't push the message to the sender, it just stores it in redis. Another endpoint is for polling the result in the return queue. This request is again is forwarded to the rmb as is.

The newer version exposes an http interface to the clients which can be the same as the old one. It has an advantage that it doesn't introduce new endpoints and is based on the same rmb processing flow. In addition, the proxy processing is isolated in its own component. And it removes the unnecessary polling between the proxy and the rmb. The disadvantage is that it's not backward compatible, and I imagine it would be more effort implementation wise compared to the check in the old proxy. And it does additional steps as a result of the wrapping, like double-verifying the wrapped and the original message, and fetching both twins public keys (the proxy will be probably cached though).