[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5280 [Obfsproxy]: obfsproxy transport functions do not understand TCP
#5280: obfsproxy transport functions do not understand TCP
-----------------------+----------------------------------------------------
Reporter: asn | Owner: asn
Type: defect | Status: new
Priority: normal | Milestone:
Component: Obfsproxy | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by nickm):
You're a little mistaken about the rules for when libevent calls a read
callback.
The only things guaranteed about read callback is that you will get a read
callback when a read adds data to a bufferevent's input buffer, and that
input buffer is greater greater than the read low watermark for that
bufferevent.
The 4096-bytes-at-a-time thing is an implementation detail that *will*
change in future versions; you can't count on it at all. It's also not
necessarily true: if read high watermarks are enabled, or rate limiting is
enabled, Libevent may read less at a time. Also, if there are less than
4096 bytes to read, Libevent will read them, and then still call the read
callback if the conditions in the last paragraph are met.
Similarly, the amount of data that will get written at a time, or that
will get written with a single syscall, is not specified by the Libevent
API. Generally, it's "as much as possible," except if rate-limiting is
enabled.
Bufferevents doesn't have access to the actual boundaries of TCP packets,
since the Berkeley Sockets API doesn't provide that. (Unless if you're
building your own packets with raw sockets or something, but that's not so
standard.) If I call send() twice in succession, that might make 3 TCP
packets, or it might make 1, or it might make 0 if the kernel is waiting
for the other side to ack data that's already been sent. So at best, all
you can hope to do is get some control over what syscalls are called, not
over what packets are generated directly. If you can rephrase what you
need in terms of syscalls, there might be a prayer of getting it, but if
you actually need direct control over packets, bufferevents can't get you
that.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5280#comment:1>
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