Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #1184

Closed (moved)
(moved)
Open
Created Dec 21, 2009 by Roger Dingledine@arma

Sending useless relay cells after the destroy cell

r9913 took out the "clear cell queue after sending destroy cell" logic.

Bug 1150 (comment 3519) points out that the cells are just going to get dropped by the other side anyway.

I think it's right.

There are three places that call connection_or_send_destroy().

The first is in relay.c, where we unlink the circ from the n_conn immediately after.

The second is in command.c, where we refuse new circuits for various reasons. No cells queued yet.

The third is in circuitlist.c, during circuit-mark-for-close. So the question is, if the circuit is marked, do we really want to still be trying to send its cells? Either it got marked from the other side, in which case the other side has already decided it doesn't want to hear from us. Or it got marked from our side, in which case either that was an error (circuit needs to die) or it has no streams on it, in which case there's no harm in clearing its queue.

Did I miss anything?

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.

Or maybe we should just pass an argument into connection_or_send_destroy() from the truncate case in relay.c saying "clear the queue please". Then we can remain ambiguous in the cases above where I said "no harm because surely the queue has nothing in it". That's certainly the safest approach, but wouldn't it be nice to simplify rather than complexify? :)

[Automatically added by flyspray2trac: Operating System: All]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking