Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #3302

Closed
Open
Created May 27, 2011 by George Kadianakis@asn

obfs2 delays sending pending data

https://trac.torproject.org/projects/tor/ticket/3202#comment:7

My current fix is not really nice, since it sends up the queued 
data only on the next proto_send(), but I didn't see a way of 
getting the correct evbuffer from inside obfs2_recv().

The problem with fixing this bug (and probably #3291 (closed)) properly is that there are not many network/libevent stuff exposed to obfs2. This is of course good, but in the case of these two bugs it forces us do ugly solutions like the above.

For example, in this case if I had access to the conn_t struct, I could use the input/output bufferevents to correctly send the pending data. In the case of #3291 (closed), I could use evtimers with the correct conn_t struct to schedule a conn_free() in the future.

To implement the above, I started creating a linked list in every listener_t that contained all the current connections on it. This is both intuitive and it would allow me to create some 'ugly but effective, and probably cleaner than other solutions' functions like get_conn_from_socks_state(socks_state_t *socks).

Any feedback on this, nickm? (and others)

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