Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • M meek
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 13
    • Issues 13
    • List
    • Boards
    • Service Desk
    • Milestones
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Anti-censorship
  • Pluggable Transports
  • meek
  • Issues
  • #24640
Closed
Open
Created Dec 15, 2017 by Kathleen Brade@brade

improve meek behavior when target server is down

As part of our testing of Tor Launcher / Moat functionality, Mark and I ran our own meek-server but intentionally stopped the BridgeDB/moat server to which it was supposed to talk. This caused a 5 minute hang within Tor Launcher before an error was generated.

On the meek-client side, we see a series of messages like these: status code was 500, not 200; trying again after 30 seconds (9)

On the meek-server side, we see these messages: dial tcp 192.168.1.xx:6790: getsockopt: connection refused

Because this is part of the Moat client implementation inside Tor Launcher, if BridgeDB is down a real person will be waiting a long time without receiving any feedback. It does not look like the retry interval or count is configurable within meek-client.

Do you have any suggestions for minimizing or eliminating the 5 minutes? We could implement a different maximum timeout inside Tor Launcher, although knowing that the underlying error is "connection refused" vs. "the network is just really slow" would make things more robust.

Assignee
Assign to
Time tracking