Thanks. The file transfer example is very informative.
I had also developed similar file transfer app over RSocket. It had a requirement that, even if the server goes down momentarily the client should resume file transfer automatically once server is up. Here, I used “spring-retry” to catch connection error and reconnect to server and resume the upload from where it left earlier. The server keeps the state of the uploaded file.
- Could RSocket protocol handle client resumption after server restarts briefly?
- If before starting the actual file transfer over a channel, some authentication and metadata transfer is required, what is the best way?
This was my logic and it worked. Please suggest if there is an alternate way.
- used RequestChannel as it is the client that sends file to server
- client sends a JSON as the first payload of the Flux to server
- JSON contains various authentication and metadata
- server validates and sends JSON response in the same channel
- both in server and client Flux.switchOnFirst(…) operator is saving my day for this logic to work
- still I need to have Flux.delaySubscription(…) of some random seconds in the client as I am afraid that the actual file transfer may get started by client before server sends validated response of the first Payload
Now, for some reason, if the server takes more time to validate the JSON, client may completely spend the delay and start sending chunks of the file. This is not desired.
I also do not want to use two TCP connections (RequestResponse and RequestChannel) from client for sending metadata and then sending file chunks. Because, this may create complication when client is multi-threaded.
I guess many would require to send intitial handshaking data to and fro between RSocket server and client. A best practice approach is needed in such scenario.