[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] Specify and implement fragmented control messages to allow ...
- To: or-cvs@xxxxxxxxxxxxx
- Subject: [or-cvs] Specify and implement fragmented control messages to allow ...
- From: nickm@xxxxxxxx (Nick Mathewson)
- Date: Wed, 2 Mar 2005 15:22:12 -0500 (EST)
- Delivered-to: archiver@seul.org
- Delivered-to: or-cvs-outgoing@seul.org
- Delivered-to: or-cvs@seul.org
- Delivery-date: Wed, 02 Mar 2005 15:22:41 -0500
- Reply-to: or-dev@xxxxxxxxxxxxx
- Sender: owner-or-cvs@xxxxxxxxxxxxx
Update of /home/or/cvsroot/tor/doc
In directory moria.mit.edu:/tmp/cvs-serv27764/doc
Modified Files:
TODO control-spec.txt
Log Message:
Specify and implement fragmented control messages to allow for (among other things) long GETINFO replies. Otherwise we could hit the 64K barrier on questions like "please dump your client-side DNS cache."
Index: TODO
===================================================================
RCS file: /home/or/cvsroot/tor/doc/TODO,v
retrieving revision 1.270
retrieving revision 1.271
diff -u -d -r1.270 -r1.271
--- TODO 2 Mar 2005 19:26:45 -0000 1.270
+++ TODO 2 Mar 2005 20:22:10 -0000 1.271
@@ -62,7 +62,9 @@
o MAPADDRESS
o Map A->B.
o Map DontCare->B.
- - Way to handle overlong messages?
+ o Way to handle overlong messages
+ o Specify fragmented format
+ o Implement fragmented format
- Event for "new descriptors"
o Better stream IDs
- EXTENDCIRCUIT <depends on revised circ selection stuff.>
Index: control-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/control-spec.txt,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -d -r1.17 -r1.18
--- control-spec.txt 23 Feb 2005 06:58:18 -0000 1.17
+++ control-spec.txt 2 Mar 2005 20:22:10 -0000 1.18
@@ -51,6 +51,11 @@
3. Message types
+ Message types are drawn from the following ranges:
+
+ 0x0000-0xEFFF : Reserved for use by official versions of this spec.
+ 0xF000-0xFFFF : Unallocated; usable by unofficial extensions.
+
3.1. ERROR (Type 0x0000)
Sent in response to a message that could not be processed as requested.
@@ -232,8 +237,6 @@
3.11. MAPADDRESS (Type 0x000A)
- [Proposal; not finalized]
-
Sent from the client to the server. The body contains a sequence of
address mappings, each consisting of the address to be mapped, a single
space, the replacement address, and a NL character.
@@ -279,8 +282,6 @@
3.12 GETINFO (Type 0x000B)
- [Proposal; not finalized]
-
Sent from the client to the server. The message body is as for GETCONF:
one or more NL-terminated strings. The server replies with an INFOVALUE
message.
@@ -304,8 +305,6 @@
3.13 INFOVALUE (Type 0x000C)
- [Proposal; not finalized]
-
Sent from the server to the client in response to a GETINFO message.
Contains one or more items of the format:
@@ -360,6 +359,32 @@
the descriptor for any reason, the server must send an appropriate error
message.
+3.17 FRAGMENTHEADER (Type 0x0010)
+
+ [Proposal; not finalized]
+
+ Sent in either direction. Used to encapsulate messages longer than 65535
+ bytes long.
+
+ Underlying type [2 bytes]
+ Total Length [4 bytes]
+ Data [Rest of message]
+
+ A FRAGMENTHEADER message MUST be followed immediately by a number of
+ FRAGMENT messages, such that lengths of the "Data" fields of the
+ FRAGMENTHEADER and FRAGMENT messages add to the "Total Length" field of the
+ FRAGMENTHEADER message.
+
+ Implementations MUST NOT fragment messages of length less than 65536 bytes.
+ Implementations MUST be able to process fragmented messages that not
+ optimally packed.
+
+3.18 FRAGMENT (Type 0x0011)
+
+ [Proposal; not finalized]
+
+ Data [Entire message]
+
4. Implementation notes
4.1. There are four ways we could authenticate, for now: