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

[Tor Bug Tracker & Wiki]

#1795: Prop 174: Optimistic Data for Tor: Server Side
-------------------------+--------------------------------------------------
 Reporter:  nickm        |       Owner:              
     Type:  enhancement  |      Status:  needs_review
 Priority:  normal       |   Milestone:              
Component:  Tor - Relay  |     Version:              
 Keywords:  prop174      |      Parent:              
-------------------------+--------------------------------------------------

Comment(by nickm):

 So, piece by piece, initial thoughts.

 '''connection.c''':

 The check for conn->state seems wrong, since the connection state's values
 are relative to the connection's type.  Only if conn->type
 ==CONN_TYPE_EXIT is it meaningful to say "conn->state ==
 EXIT_CONN_STATE_anything".

 On the other hand, if what we're really concerned about is the possible
 absence of conn->write_event, we could as easily check for
 conn->write_event rather than the state.

 The same note applies to the second check for conn->state in the
 tor_assert below.

 '''relay.c''':

 Rather than special-casing the code that called
 connection_edge_process_relay_cell_not_open(), could we not move the new
 handling for DATA cells *into*
 connection_edge_process_relay_cell_not_open() ?  Or would that make stuff
 ugly? (Again, you need to check conn->type before conn->state is
 meaningful)

 ' log_warn(domain, "Optimistic data received."); ' is debugging code.

 I worry that making the consider_sending_sendme() calls conditional might
 put us in a position where they could never be called.  If a client
 exhausts the window of a sendme cell before the resolve and connect are
 done, will a sendme eventually be sent?  If so, what calls it?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1795#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online