[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1826 [Tor Relay]: Sending packets after RELAY_END
#1826: Sending packets after RELAY_END
-----------------------+----------------------------------------------------
Reporter: mwenge | Owner:
Type: defect | Status: new
Priority: normal | Milestone: Tor: 0.2.2.x-final
Component: Tor Relay | Version: Tor: unspecified
Keywords: | Parent:
-----------------------+----------------------------------------------------
Comment(by nickm):
Interesting!
If these cells are getting sent after the RELAY_END arrives at an exit
node, they are probably coming because [case 1] they're already in the
cell queue or [case 2] in the connection_or's outbuf. Unless [case 3]
data in the connection_edge's inbuf is somehow getting packaged even after
a the RELAY_END cell arrives.
It's also possible [case 4] that some of the cells are already in transit
(queued somewhere between the exit node's SSL and the client's Tor) when
the client sends the RELAY_END cell. We can't really do anything about
those.
So, breaking down the cases:
case 1: cells already on the cell_queue) We don't have a good way to
remove cells from a circuit's cell queue now at all. By the time they get
there, they're encrypted and ready for delivery. Removing them would
throw of the circuit's stream cipher. Furthermore, the cells are already
packed at that point, so figuring out what streams they went with would be
nontrivial.
We could mitigate this by lowering how full we're willing to fill a cell
queue with cells from streams before we stop reading from the streams.
This might help stream fairness. I don't know what it would do to
performance.
In Tor 0.2.3.x, we're going to have to change the point at which we
encrypt cells on queues in order to implement #1479. When we do this, we
can revisit the possibility of removing already-queued cells for a dead
stream.
case 2: cells already in the connection_or's outbuf) This is way too late
to remove the cells.
We could mitigate this by lowering how much we're willing to fill an
connection_or's outbuf.
case 3: packaging cells from an exit connection even after getting a
relay_end) That would be a bug. If it's happening, we should fix it.
case 4: the cells are in transit on the net) There's nothing we can do
about that with our current protocol.
So IMO the right thing to do is make sure that case 3 isn't happening, and
think about what tuning we could do to mitigate 1 and 2, and whether it's
a net win or not.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1826#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