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
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

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
  • #9

Closed
Open
Opened Nov 14, 2004 by weasel (Peter Palfrader)@weasel

Client MMTP timeouts don't really work

[Moved from bugzilla] Reporter: nickm@alum.mit.edu (Nick Mathewson)

Description: Opened: 2003-10-17 13:28

Right now, client MMTP connections only timeout while the connect(2) call is in progress. But there is no good way (other than alarm(2)) to have blocking TLS connections timeout.

The symptom is: connect to server that accepts a TCP connection, but that never completes any TLS operations. The client will block forever.

For now, I'm implementing alarm() for a quick fix. But that will penalize slow servers, and isn't a good long-term solution.

The real answer is probably to rewrite the client and server connection to both use a common set of nonblocking IO calls.

------- Additional Comments From Nick Mathewson 2004-01-27 01:57 -------

This has been fixed by the MMTP rewrite in 0.0.7.

[Automatically added by flyspray2trac: Operating System: All]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#9