ResponseConsumer: pass resp to constructor (nfc)

[hippotat.git] / PROTOCOL

diff --git a/PROTOCOL b/PROTOCOL
index 9969e61bb1f3ed30d055642e97d7ec4382ee7e57..e18cf0e1554da169e6ffdcd8994ba3a727f8c17c 100644 (file)
--- a/PROTOCOL
+++ b/PROTOCOL
@@ -1,27 +1,42 @@
 Server maintains a queue of outbound packets for each user
 
-Packets which are older than MAX_QUEUE_TIME are discarded
+Packets which are older than the applicable max_queue_time are discarded
 
-Each incoming request to the server takes up to MAX_BATCH_DOWN bytes
+Each incoming request to the server takes up to max_batch_down bytes
 from the queue and returns them as the POST response body payload
 
-Each incoming request contains up to MAX_BATCH_UP bytes of payload.
+Each incoming request contains up to max_batch_up bytes of payload.
 It's a multipart/form-data.
 
-Authentication: for now, plaintext password
+Authentication: clock-based lifetime-limited bearer tokens.
 
-Sever side configuration:
- Per user but normally global
-  MAX_MAX_BATCH_DOWN MAX_MAX_QUEUE_TIME
- Global
-  MTU
- Per user
-  PASSWORD
+Encryption and integrity checking: none.  Use a real VPN over this!
 
-Client side configuration;
- MAX_BATCH_DOWN MAX_QUEUE_TIME PASSWORD
+Routing assistance: none in hippotat; can be requested on client
+ from userv-ipif via `vroutes' parameter.  Use with secnet polypath
+ ideally uses the special support in secnet 0.4.x.
 
-Routing assistance: none needed; secnet polypath will DTRT
+Client form parameters (multipart/form-data):
+ m             metadata, newline-separated list (text file) of
+                       client ip address (textual)
+                       token
+                       target_requests_outstanding
+                       http_timeout
+ d              data (SLIP format, with SLIP_ESC and `-' swapped)
 
-Client form parameters:
- I MBD MQT P D
+
+Authentication token is:
+        <time_t in hex with no leading 0s> <hmac in base64>
+(separated by a single space).  The hmac is
+        HMAC(secret, <time_t in hex>)
+
+
+Possible future nonce-based authentication:
+
+server keeps big nonce counter for each client
+meaning is:
+ nonce counter is most recent nonce client has sent
+also server keeps bitmap of the previous ?64 nonces,
+ whether client has sent them
+
+client picks.... xxx