[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [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: 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs