Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 316
    • Issues 316
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 36
    • Merge requests 36
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #1850
Closed
Open
Created Aug 21, 2010 by Roger Dingledine@armaReporter

Proposal 174: Optimistic Data for Tor, relay side

To support optimistic data for web browsing, exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.

Ian wrote proposal 174 to start us off here: https://gitweb.torproject.org/tor.git/blob/master:/doc/spec/proposals/174-optimistic-data-server.txt http://archives.seul.org/or/dev/Aug-2010/msg00001.html

Step one is to evaluate the proposal to see if it is actually what we want.

Sure would be nice to have some guesses about what the other proposals (other parts of legacy/trac#1849 (moved)) will look like, in order to know if proposal 174 does what we want. :)

Step two is to evaluate the patch that came with it, and see if it implements what we thought we wanted.

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