Changes between Initial Version and Version 2 of Ticket #1184

Jul 30, 2010, 10:56:52 PM (9 years ago)

So if the destroy cell is outgoing, the client really won't process any cells on the circuit, so it's safe for the client to clear the queue. And if it's incoming at a relay, it's going to turn into a truncated, and get queued up behind all the other relay cells for the client. And if it's incoming at a client, there is currently no cell queue there at all, since we crypt cells aggressively on receiving them. So I am pretty sure that clearing cell queues on circuit_mark_for_close is a safe thing to do. I don't think we _were_ sending any cells in these cases, but if we were, they weren't getting processed.

The one case that puzzles me is RELAY_COMMAND_TRUNCATE. We call connection_or_send_destroy() there. But do we really mean to cancel every relay cell that the intermediate relay received before the TRUNCATE command but has not yet relayed, or do we mean them to go on their way? I think it's safe to cancel them given how Tor works now, but our spec doesn't envision that possibility.

Perhaps we should check, in main.c when we're considering whether to mark it because it's idle, whether there are any cells still in its queue.

You were talking about connections, perhaps? I don't see anywhere in main.c where we close idle circuits. But connections don't have cell queues; circuits do.

Anyway, I've hacked up a fix. See branch bug1184 in my public repository.


  • Ticket #1184

    • Property Status changed from new to needs_review
    • Property Milestone changed from 0.2.2.x-final to Tor: 0.2.2.x-final