mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2025-02-22 06:21:55 +01:00
finally write some comments on tor-spec-udp.txt
svn:r6455
This commit is contained in:
parent
f6c9741c83
commit
08fd72fb06
1 changed files with 25 additions and 0 deletions
|
@ -387,3 +387,28 @@ Switching to UDP means managing the queues of incoming packets better,
|
|||
so we don't miss packets. How does this interact with doing large public
|
||||
key operations (handshakes) in the same thread?
|
||||
|
||||
========================================================================
|
||||
COMMENTS
|
||||
========================================================================
|
||||
|
||||
[16 May 2006]
|
||||
|
||||
I don't favor this approach; it makes packet traffic partitioned from
|
||||
stream traffic end-to-end. The architecture I'd like to see is:
|
||||
|
||||
A *All* Tor-to-Tor traffic is UDP/DTLS, unless we need to fall back on
|
||||
TCP/TLS for firewall penetration or something. (This also gives us an
|
||||
upgrade path for routing through legacy servers.)
|
||||
|
||||
B Stream traffic is handled with end-to-end per-stream acks/naks and
|
||||
retries. On failure, the data is retransmitted in a new RELAY_DATA cell;
|
||||
a cell isn't retransmitted.
|
||||
|
||||
We'll need to do A anyway, to fix our behavior on packet-loss. Once we've
|
||||
done so, B is more or less inevitable, and we can support end-to-end UDP
|
||||
traffic "for free".
|
||||
|
||||
(Also, there are some details that this draft spec doesn't address. For
|
||||
example, what happens when a UDP packet doesn't fit in a single cell?)
|
||||
|
||||
-NM
|
||||
|
|
Loading…
Add table
Reference in a new issue