[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #1795 [Tor - Relay]: Prop 174: Optimistic Data for Tor: Server Side

#1795: Prop 174: Optimistic Data for Tor: Server Side
-------------------------+--------------------------------------------------
 Reporter:  nickm        |       Owner:     
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:     
Component:  Tor - Relay  |     Version:     
 Keywords:  prop174      |      Parent:     
-------------------------+--------------------------------------------------
 Attached is Ian's patch to implement the server side of proposal 174.  The
 goal is to accept and queue DATA cells received at an exit when the
 connection is not yet opened.

 Notes from Ian:

    The current code actually correctly handles queued data at the Exit; if
 there is queued data in a EXIT_CONN_STATE_CONNECTING stream, that data
 will be immediately sent when the connection succeeds.  If the connection
 fails, the data will be correctly ignored and freed.  The problem with the
 current server code is that the server currently drops DATA cells on
 streams in the EXIT_CONN_STATE_CONNECTING state. Also, if you try to queue
 data in the EXIT_CONN_STATE_RESOLVING state, bad things happen because
 streams in that state don't yet have conn->write_event set, and so some
 existing sanity checks (any stream with queued data is at least
 potentially writable) are no longer sound.

    The solution is to simply not drop received DATA cells while in the
 EXIT_CONN_STATE_CONNECTING state.  Also do not send SENDME cells in this
 state, so that the OP cannot send more than one window's worth of data to
 be queued at the Exit.  Finally, patch the sanity checks so that streams
 in the EXIT_CONN_STATE_RESOLVING state that have buffered data can pass.

    [...] Here is a simple patch.  It seems to work with both regular
 streams and hidden services, but there may be other corner cases I'm not
 aware of. (Do streams used for directory fetches, hidden services, etc.
 take a different code path?)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1795>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs