Re: [tor-dev] Torsocks development status

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev