Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • briar briar
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 783
    • Issues 783
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 9
    • Merge requests 9
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • briar
  • briarbriar
  • Issues
  • #45

Closed
Open
Created Dec 01, 2015 by akwizgran@akwizgranOwner

Reduce mobile data consumption

Briar uses a lot of bandwidth considering the small amount of data it transfers. The most likely culprit is the Tor plugin, which maintains circuits to several introduction points and regularly tries to build circuits to contacts' introduction points. Can we reduce the amount of bandwidth it uses?

Ricochet has a nice solution to this: each time we (re)connect to Tor, try to connect to our peers, and while we remain connected, expect them to connect to us rather than vice versa.

https://github.com/ricochet-im/ricochet/issues/68

There may be a race condition, however, if our hidden service doesn't become reachable until after we've polled our contacts' services. Can we poll our own hidden service to check its reachability?

Another possible culprit is the LAN plugin, which will bind to an interface with a non-local address if no local address is available. This is meant to enable the plugin to work on internal networks that use non-local addresses, such as UCL -- but it may also lead to observable connections across the WAN, so perhaps we should change it.

Edited Nov 16, 2020 by akwizgran
Assignee
Assign to
Time tracking