[tor-bugs] #3302 [Pluggable transport]: obfs2 delays sending pending data

[Tor Bug Tracker & Wiki]

#3302: obfs2 delays sending pending data
---------------------------------+------------------------------------------
 Reporter:  asn                  |          Owner:  asn
     Type:  defect               |         Status:  new
 Priority:  normal               |      Milestone:     
Component:  Pluggable transport  |        Version:     
 Keywords:                       |         Parent:     
   Points:                       |   Actualpoints:     
---------------------------------+------------------------------------------

Comment(by asn):

 Hi rransom! Thanks for the interest.

 Replying to [comment:2 rransom]:
 > Replying to [ticket:3302 asn]:
 > > 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) 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.
 >
 > Then specify the `conn_t *` as the ‘user data’ for the libevent
 callbacks you're using.
 >

 Passing `conn_t *` to proto_recv() just for the case that we have pending
 data (which generally shouldn't happen) *on the obfs2 protocol* is quite
 ugly as well, isn't it?

 > > In the case of #3291, I could use `evtimer`s 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)`.
 >
 > What if two connections are in the same SOCKS state?

 SOCKS state is created per-connection basis and is attached to the `conn_t
 *` like this:
 {{{
 conn->socks_state = socks_state_new();
 }}}

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3302#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online