Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #1184

Closed (moved)
Open
Opened 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 admin enable hashed storage. More information
Assignee
Assign to
Tor: 0.2.2.x-final
Milestone
Tor: 0.2.2.x-final
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#1184