commit d126abf39b512b49f5713cd2fcda6230ba75f1e9
Author: Philippe PITTOLI
Date: Tue Dec 17 22:08:54 2019 +0100
README, with a rationale draft.
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5948af2
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,5 @@
+shard.lock
+bin
+lib
+
+.*
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..e5643f3
--- /dev/null
+++ b/README.md
@@ -0,0 +1,42 @@
+# protocol overview
+
+1. AUTHENTICATION: authentication message and informations about messages to transfer
+2. RESPONSE: OK or ERROR
+3. loop:
+ # TRANSFER: message id, file chunk
+ # REPONSE: Ok
+
+# messages content
+
+format: IPC USER MESSAGE TYPE, JSON ENCODED MESSAGE
+
+1. AUTHENTICATION message
+ 1, { message-id: "UUID", token: "JWT", files: [
+ { name: "NAME", size: SIZE-IN-BYTES (unsigned int 64 bits) },
+ { name: "NAME", size: SIZE-IN-BYTES (unsigned int 64 bits) },
+ ], fid: "UUID", tags: [ TAG-NAME, TAG-NAME ]
+ }
+ note: The server knows the user id from the token (JWT) and stores the received files in a
+2. RESPONSE message
+ 2, { message-id: "UUID", response: "Ok" }
+ or
+ 2, { message-id: "UUID", response: "Error", reason: "REASON" }
+3. TRANSFER message
+ 3, { message-id: "UUID", chunk: "UUID", data: [ BINARY DATA ] }
+
+# Rationale
+
+### Why don't we just trust TCP to carry the whole file?
+The application layer has to know which parts are missing so we can transfer them later (in another connection, maybe).
+
+### Why message id?
+The client and the server do not have a direct TCP connection together, there may be proxies.
+The client cannot trust its TCP connection to know exactly what are the parts the server really got.
+The file server to proxy connection can be dropped, we have to ensure the communication between the client and the server.
+
+
+# How this works:
+
+* libipc is used to communicate
+* messages are: JSON encoded, 1KB buffered data
+* message example: { message-id: "UUID", chunk: "UUID", data: [1KB BINARY DATA] }