smartdevicelink / sdl_requirements

Collection of requirements/technical tasks for new sdl_core features
BSD 3-Clause "New" or "Revised" License
2 stars 7 forks source link

[Expand Mobile putFile RPC] SDL expected behavior #64

Open AByzhynar opened 6 years ago

AByzhynar commented 6 years ago

Hello @lchen139 and @tpulatha Please help to clarify some questions regarding proposal: 0037-Expand-Mobile-putfile-RPC.md The proposal says:

This paired with the ability to upload very large files as chunks using the offset and length parameters of putFile results in the problem that an App might upload a very large file (say 1GB) and gets a SUCCESS for each small putFile. But when the complete file gets CRC checked on the head unit, this check fails because one putFile had a missing frame that went unnoticed.

1) So in case of app sends very large file as chunks - every small PutFile will send CRC checksum for every chunk, right? (Not for entire file). And in case of CRC checksum mismatch SDL core will send the putFile response with these values:

resultCode: CORRUPTED_DATA info: "CRC Check on file failed. File upload has been canceled, please retry." success: false

for every small PutFile ?

2) What if one of the chunks in the middle has failed CRC checksum but mobile app continues sending the rest of chunks and the next ones were successful - there is no sense to upload such file to the system. What SDL behaviour do you expect?

AByzhynar commented 6 years ago

@KhrystynaDubovyk Please be aware

lchen139 commented 6 years ago

@AByzhynar Questions 1: CRC checksum is for each small putfile. entire file validation is due to vehicle function to handle that. Question 2: We are assume app shall handle CORRUPTED_DATA response code. if app miss that and continue sending next chunk, vehicle function shall send File_Resume at an given interval(not sure if it is sent at each putfile or after certain amount of putfile). This mismatch in File_Resume offset will let app know it did wrong. after this point, we are assuming vehicle side will failed at entire file validation and restart this process so app can stream whatever data to trigger this point.

don't know if there is anyother possible way to handle this. @tpulatha please provide your suggestions.

AByzhynar commented 6 years ago

@lchen139 So please confirm that I am right in the following:

App -> SDL : PutFile request (syncFileName, fileType, offset = 0, length, crc) - CRC check passed
SDL -> App : PutFile response (resultCode=SUCCESS, spaceAvailable) 
App -> SDL : PutFile request (syncFileName, fileType, offset = 100, length, crc) - CRC check passed
SDL -> App : PutFile response (resultCode=SUCCESS, spaceAvailable) 
App -> SDL : PutFile request (syncFileName, fileType, offset = 200, length, crc) - CRC check FAILED
SDL -> App : PutFile response (resultCode=CORRUPTED_DATA, spaceAvailable) 

In case app continues sending chunks:

App -> SDL : PutFile request (syncFileName, fileType, offset = 300, length, crc) - CRC check PASSED
SDL -> App : PutFile response (resultCode=INVALID_DATA, spaceAvailable) 

for all next PutFile requests with not null offset and not writing file to file system. Is this behavior correct and expected?

AByzhynar commented 6 years ago

@lchen139 Any updates regarding last question?

lchen139 commented 6 years ago

@AByzhynar Yes, that aligns with my expectation. App putfile with wrong offset, SDL shall discard that incoming putfile(with wrong offset) and provide a negative response to notify app.

AByzhynar commented 6 years ago

@lchen139 Thank you very much