@@ -23,8 +23,6 @@ Depending on the TYPE, a Request may have a response.
### OFFER
An OFFER request indicates that the connected peer wants to send a chunked file to the recipient.
+**RESPONSE:** yes
+**BODY:** [FILE_ID, NUM_CHUNKS ,CONTACT_ID]
+**FILE_ID:***[BDF raw]* A unique identifier which specifies the offered file. *NOTE: The identifier is the encrypted stream's sha256 sum and is also used to verify the file*
...
...
@@ -32,15 +30,28 @@ An OFFER request indicates that the connected peer wants to send a chunked file
+**CONTACT_ID:***[BDF long/null]* Either `Null`, if the contact's id is identified by the connection (A contact of the owner connecting to the owner's mailbox is only allowed to store their own streams) or `Integer` to indicate for which id the stream should be stored (Used by the owner storing streams for contacts without their own mailbox)
+**RESPONSE:** yes
+**BODY:** [MISSING_CHUNKS]
+**MISSING_CHUNKS:***[list of BDF long]* Missing chunk indices
### CHUNK
A CHUNK request contains a chunk of a previously *offered* file. *Note: Since the OFFER request already specifies the contact's Id, we do add the contact's id to the CHUNK request*
+**RESPONSE:** yes
+**BODY:** [CHUNK_INDEX, CHUNK]
+**CHUNK_INDEX:***[BDF long]* Defines the chunk's index in the chunked file
+**CHUNK:***[BDF raw]* chunk
+**RESPONSE:** yes (Functions as ACK)
+**BODY:**``null`
### CHUNK_FIN
A CHUNK_FIN request indicates that the last ACK for the given file id's chunk requests has been received. The recipient is then able to confidently delete the file. *NOTE: Without the CHUNK_FIN request a file could theoretically be resent if the last ACK request is lost.*
+**BODY:** [FILE_ID]
+**FILE_ID:***[BDF raw]* file id
+**RESPONSE:** no
### SYNC
SYNC requests are used to carry [BSP](https://code.briarproject.org/briar/briar-spec/blob/master/protocols/BSP.md) messages between the mailbox and the connected client.
