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
Copy file name to clipboardExpand all lines: README.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,7 +55,7 @@ Sync360 has a working Android-to-Android MVP for text and multiple-file transfer
55
55
- Stream file bytes directly over raw TCP without loading an entire file into memory.
56
56
- Save received files into public Android Downloads through `MediaStore`, preserving the extension when duplicate names are resolved.
57
57
- Delete the incomplete current file if its receive operation fails or is cancelled.
58
-
-Send files sequentially with a save acknowledgement after each file.
58
+
-Stream each accepted file batch continuously, then confirm the batch with one final receiver result.
59
59
- Cancel a pending send or active file transfer on a best-effort basis.
60
60
- Show batch-wide byte percentage while files are being sent and received.
61
61
- Show clear offer, transfer, success, failure, and cancelled states on the sender, with incoming, receiving, and received states on the receiver.
@@ -122,10 +122,10 @@ Platform file picker
122
122
-> platform FileTransferSender opens an InputStream
123
123
-> one raw TCP connection streams the accepted file batch
124
124
-> platform DownloadsWriter saves each file
125
-
-> receiver acknowledges that the file was saved
125
+
-> receiver returns final success and completed-file count
126
126
```
127
127
128
-
One TCP socket is opened for the complete accepted batch. Each file begins with its index and promised byte count, followed by exactly that many bytes. The receiver checks the index and size against the accepted offer before saving the file, then sends one save acknowledgement before the sender continues. The current shared payload buffer is 512 KiB; TCP correctness does not depend on sender and receiver reads using identical chunk boundaries.
128
+
One TCP socket is opened for the complete accepted batch. Each file begins with its index and promised byte count, followed by exactly that many bytes. The receiver checks the index and size against the accepted offer before saving each file. The sender writes every file sequentially, flushes once after the complete batch, then reads one final success flag and completed-file count from the receiver. The count increases only after the platform Downloads writer successfully returns. The current shared payload buffer is 512 KiB; exact byte counts define file boundaries, so correctness does not depend on `flush()` calls or matching sender and receiver read chunks.
129
129
130
130
Files are sent sequentially. If a later file fails, files that were already completed stay in Downloads; the incomplete current file is cleaned up. Android uses a pending `MediaStore` entry and resolves its MIME type from the filename extension so duplicate names remain in the form `file (1).ext`. Desktop writes a temporary `.part` file before moving a completed file into place without overwriting an existing name.
Copy file name to clipboardExpand all lines: context.md
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -51,11 +51,12 @@ Raw TCP is the file data plane:
51
51
52
52
```text
53
53
one connection per accepted batch
54
-
-> file index
55
-
-> promised byte count
56
-
-> exact file bytes
57
-
-> save acknowledgement
58
-
-> next file
54
+
-> repeat for each file:
55
+
-> file index
56
+
-> promised byte count
57
+
-> exact file bytes
58
+
-> sender flushes once
59
+
-> receiver returns final success and completed-file count
59
60
```
60
61
61
62
Current shared transfer constants use a 512 KiB payload buffer, 5-second connect timeout, 60-second connected-socket timeout, and 10-second wait for the first file connection after acceptance.
Copy file name to clipboardExpand all lines: docs/ARCHITECTURE.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -101,14 +101,16 @@ Accepted file bytes use a separate raw TCP connection:
101
101
102
102
```text
103
103
one connection for the accepted batch
104
-
-> file index: Int
105
-
-> promised file size: Long
106
-
-> exactly promised-size bytes
107
-
-> receiver save acknowledgement: Boolean
108
-
-> repeat for the next file
104
+
-> repeat for each accepted file:
105
+
-> file index: Int
106
+
-> promised file size: Long
107
+
-> exactly promised-size bytes
108
+
-> sender flushes after the complete batch
109
+
-> receiver result: Boolean
110
+
-> completed-file count: Int
109
111
```
110
112
111
-
Files remain sequential. The receiver verifies each index and size against the accepted offer before saving. It acknowledges a file only after the platform Downloads writer completes it.
113
+
Files remain sequential. The receiver verifies each index and size directly against the matching file in the accepted offer before saving. It increments the completed-file count only after the platform Downloads writer returns successfully. After every file has been processed, the receiver sends one final success flag and completed count. If processing fails, it attempts to send `false` with the number of files that were fully saved.
112
114
113
115
`FileTransferConstants` currently provides:
114
116
@@ -117,7 +119,7 @@ Files remain sequential. The receiver verifies each index and size against the a
117
119
- 60-second connected-socket timeout
118
120
- 10-second wait for the first file connection after acceptance
119
121
120
-
The sender and receiver do not need matching read boundaries because TCP is a byte stream; exact file sizes define the protocol framing.
122
+
The sender and receiver do not need matching read boundaries because TCP is a byte stream; exact file sizes define the protocol framing. Flushing once after the batch makes any remaining buffered bytes available before the sender waits for the final result, but the flush does not define file boundaries.
0 commit comments