You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
RMB (relay) and messages can totally support file upload without changes. While it's a message protocol a message payload can be anything (for example chunk of a file) hence 2 peers implementing the protocols can perfectly agree to upload a file over multiple chunks and communicate ahead of the upload.
Things get a little bit more complicated when the rmb-peer implementation comes in between. the rmb-peer job is to implement a "gateway" that can run locally and then send and receive messages on behalf on multiple apps that can be running next to each other on the same local machine. It receive a request from a local machine, send it to remote peer, wait for answer and then send it back to the original caller.
For file upload the requirements state that, the local app send a request to the local peer, that peer then take care of communicating the file upload with the remote rmb-peer, then implement the upload (over chunks) or communicate errors back to the caller.
This sounds easier than in reality duo to async nature of the protocol. The rmb-peer then need to be changed a little bit to add more layers where we can inject application behavior (like extensions) inside peer itself.
Anyway this is about the research needed to be done to implement the right architecture to support this
The text was updated successfully, but these errors were encountered:
Related to #103
Introduction
RMB (relay) and messages can totally support file upload without changes. While it's a message protocol a message payload can be anything (for example chunk of a file) hence 2 peers implementing the protocols can perfectly agree to upload a file over multiple chunks and communicate ahead of the upload.
Things get a little bit more complicated when the
rmb-peer
implementation comes in between. thermb-peer
job is to implement a "gateway" that can run locally and then send and receive messages on behalf on multiple apps that can be running next to each other on the same local machine. It receive a request from a local machine, send it to remote peer, wait for answer and then send it back to the original caller.For file upload the requirements state that, the local app send a request to the local peer, that peer then take care of communicating the file upload with the remote rmb-peer, then implement the upload (over chunks) or communicate errors back to the caller.
This sounds easier than in reality duo to async nature of the protocol. The rmb-peer then need to be changed a little bit to add more layers where we can inject application behavior (like extensions) inside peer itself.
Anyway this is about the research needed to be done to implement the right architecture to support this
The text was updated successfully, but these errors were encountered: