Resumable file transfer

Created separate thread to discuss file transfer with resumption

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.

Doubts :

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.


Could RSocket protocol handle client resumption after server restarts briefly?

Currently RSocket-java supports warm resumption - that means processes of client and server are not destroyed, and there is connectivity loss between them only. Restarting client or server requires support for cold resumption - this needs means for storing session information between restarts (token, some state related resumption protocol) and durable frames store - not supported yet unfortunately.

Thanks for the clarification regarding warm resumption.

For my other query, I just found that initial authentication and metadata transfer can be done in a requestResponse(…) and then send file chuck in requestChannel(…), both using a single RSocket connection.

One more observation -
For uploading a file from client to server, I need to use RequestChannel(…) where client sends Flux[FileChunk] and server returns back Flux [Void]. In your example, you have used RequestStream as client is requesting a file to download.

How much performance hits are expected in RequestStream vs RequestChannel where the later is returning only Flux of Void?

Are there any workarounds that could be implemented on the application level to support cold resumption in some form (no need to replay not delivered messages)?