On Thu, Jun 27, 2013 at 05:39:08PM -0400, David Goulet wrote:
Matthew Finkel:
On Thu, Jun 27, 2013 at 03:11:23PM -0400, David Goulet wrote:
Ian Goldberg:
Are non-blocking sockets, select/poll/etc. (especially at connect() time), and optimistic data on the to-do list?
Yes! Good point I should have put the todo list. So yes, non block socket support.
For optimistic data, it is kind of tricky.
It definitely is tricky. You just need to find the best way to have torsocks return the least untrue response that's allowed by the OS. I'm not going to reiterate what Ian said, but I'll just make some points about what I did.
I can use it for DNS resolution without a problem because torsocks control the complete flow of data from opening a SOCKS5 connection to closing it after the DNS response is received however for actual real data (sendmsg, send, ...) a connect is needed before so it would means that a connect() call will return "yes OK socket connected" but where in fact it is not really true. So, when the first data are sent, there is a possibility that the Tor connections failed or even we block for an unknown amount of time during the send*/write() call.
Yup, this is exactly the case (in addition to SOCKS4/A also).
Actually, I did not see any reasons why this rewrite should support SOCKS4. Is there ?
As far as I know, latency is probably the reason SOCKS4 is still useful, but you can leave it on the TODO list as "patches welcome" if you don't think it's too important.
Regarding poll(), torsocks really needs to wrap the multiplexing I/O syscalls ({p,}poll, {p,}select, epoll, kqueue, etc) or else you will run into some major problems (select() and poll() being much more important than the others). This is intrusive, but it's only a single write request (for all values of "write").
Can you detail why it's very important? You did some hacking in the old code base and I would like to know your experience on that. What possible major problems? What happens if it's not hijacked?
Hrm. So my initial response was "Everything breaks :)" but then I thought about this and that's actually not true, at all. The real benefit to hijacking them is to progress the SOCKS handshake with a single select()/poll() from the client app rather than multiple calls. So, in retrospect, I'm not sure how important this is. I now realize I was actually thinking about another bug.
Personally, I think the most important feature of the optdata implementation is that you make it configurable.
By configurable you mean disabled or not ? What else is there to configure?
Yeah, sorry, I only meant the ability to enable/disable it, unless you can think of other nifty features to add.
Thanks! David
Cheers! David
Thanks,
- Ian
- Matt