[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 iang):
You're totally right about checking for CONN_TYPE_EXIT, of course. I must
have been confused by a quick glance at or.h and seeing that the EXIT and
AP states were disjoint, and not noticing that the others are not.
Checking for write_event in chunk 1 is also a plausible solution; in chunk
2, I think the state check (suitably corrected to also check for
CONN_TYPE_EXIT) is the right choice.
I don't think we want to move code into
connection_edge_process_relay_cell_not_open(), since the patch causes
control to skip that call, and fall through to the RELAY_COMMAND_DATA
handling below. All that stuff would have to be copied into
connection_edge_process_relay_cell_not_open(), which seems poor.
Agreed on the debugging code; sorry that slipped in.
Isn't it the case that when the cells get *sent* to the server, it will
trigger the check to see if SENDMEs should be sent? SENDMEs are sent when
the buffer empties, not when it fills, right? I expect that not wrapping
these calls would have the same (i.e. no) effect, but it seems cleaner to
me to not check if you should send a SENDME if you know you won't.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1795#comment:4>
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