[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #3302 [- Select a component]: obfs2 delays sending pending data
#3302: obfs2 delays sending pending data
----------------------------------+-----------------------------------------
Reporter: asn | Owner: asn
Type: defect | Status: new
Priority: normal | Milestone:
Component: - Select a component | Version:
Keywords: | Parent:
Points: | Actualpoints:
----------------------------------+-----------------------------------------
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.
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)`.
Any feedback on this, nickm? (and others)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3302>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs