1. 16 Dec, 2021 2 commits
  2. 15 Dec, 2021 1 commit
    • Nick Mathewson's avatar
      Extend trace messages for destroy/truncated reasons. · f7384054
      Nick Mathewson authored
      It makes sense to put the method for human-readable strings onto the
      type itself, so that we can format these whenever they occur.
      I'm choosing the "human_str" method name here, since caret-generated
      types already have a to_str.  I was thinking about using Display,
      but caret types already implement that.
      I've also moved the message from "warn!" to "debug!", since these
      aren't necessarily a problem condition.
  3. 14 Dec, 2021 4 commits
  4. 13 Dec, 2021 2 commits
  5. 08 Dec, 2021 1 commit
  6. 06 Dec, 2021 1 commit
    • Nick Mathewson's avatar
      Resolve roughly half of the XXXXs. · 31b385c5
      Nick Mathewson authored
      We want to only use TODO in the codebase for non-blockers, and open
      tickets for anything that is a bigger blocker than a TODO.  These
      XXXXs seem like definite non-blockers to me.
      Part of arti#231.
  7. 24 Nov, 2021 1 commit
  8. 12 Nov, 2021 2 commits
    • eta's avatar
      Get rid of unbounded stream sender, and RawCellStream · c5597541
      eta authored
      Previously, the reactor would use an `UnboundedSender` to send things to
      the `RawCellStream`, in order that the reactor wouldn't block if you
      failed to read from the latter. This is bad, though, since it means
      people can just run us out of memory by sending lots of things.
      To fix this, we make the new `StreamReader` type (which does the reading
      parts from `RawCellStream`) keep track of the stream's receive window
      and issue SENDMEs once *it* has consumed enough data to require it, thus
      meaning that we shouldn't get sent enough data to fill the channel
      between reactor and `StreamReader` (and, if we do, that's someone trying
      to flood us, and we abort the circuit).
      As hinted to above, the `RawCellStream` was removed and its reading
      functionalities replaced by `StreamReader`; its writing functionalities
      are handled by `StreamTarget` anyway, so we just give out one of those
      for the write end. This now means we don't need any mutexes!
      note: this commit introduces a known issue, arti#230
    • eta's avatar
      Completely overhaul the tor-proto circuit reactor · 197816d1
      eta authored
      Rather like e8e9699c ("Get rid of
      tor-proto's ChannelImpl, and use the reactor more instead"), this
      admittedly rather large commit refactors the way circuits in `tor-proto`
      work, centralising all of the logic in one large nonblocking reactor
      which other things send messages into and out of, instead of having a
      bunch of `-Impl` types that are protected by mutexes.
      Congestion control becomes a lot simpler with this refactor, since the
      reactor can manage both stream- and circuit-level congestion control
      unilaterally without having to share this information with consumers,
      meaning we can get rid of some locks.
      The way streams work also changes, in order to facilitate better
      handling of backpressure / fairness between streams: each stream now has
      a set of channels to send and receive messages over, instead of sending
      relay cells directly onto the channel (now, the reactor pulls messages
      off each stream in each map, and tries to avoid doing so if it won't be
      able to forward them yet).
      Additionally, a lot of "close this circuit / stream" messages aren't
      required any more, since that state is simply indicated by one end of a
      channel going away. This should make cleanup a lot less brittle.
      Getting all of this to work involved writing a fair deal of intricate
      nonblocking code in Reactor::run_once that tries very hard to be mindful
      of making backpressure work correctly (and congestion control); the old
      code could get away with having tasks .await on things, but the new
      reactor can't really do this (as it'd lock the reactor up), so has to do
      everything in a nonblocking manner.
  9. 02 Nov, 2021 1 commit
  10. 27 Aug, 2021 2 commits
  11. 24 Aug, 2021 1 commit
  12. 20 Aug, 2021 1 commit
  13. 06 Aug, 2021 1 commit
  14. 22 Jun, 2021 1 commit
  15. 14 Jun, 2021 1 commit
  16. 28 May, 2021 1 commit
  17. 26 May, 2021 1 commit
  18. 03 May, 2021 1 commit
  19. 16 Mar, 2021 1 commit
  20. 02 Dec, 2020 1 commit
  21. 01 Dec, 2020 1 commit
  22. 13 Nov, 2020 1 commit
  23. 12 Nov, 2020 1 commit
  24. 27 Oct, 2020 2 commits
  25. 26 Oct, 2020 3 commits
  26. 23 Oct, 2020 1 commit
  27. 22 Oct, 2020 1 commit
  28. 21 Oct, 2020 1 commit
  29. 20 Oct, 2020 1 commit
  30. 18 Oct, 2020 1 commit
    • Nick Mathewson's avatar
      Mark must-resolve XXXX issues with "XXXXM3". · 55231346
      Nick Mathewson authored
      "M3" is for "milestone 3" -- my target to fix the technical debt
      that I think will be bad if we ship even a pre-alpha with it.
      These aren't necessarily _all_ must-resolve, but they're all
      Closes #15