On Sat, Dec 24, 2011 at 2:44 PM, Lee Fisher <blib...@gmail.com> wrote: > On 12/22/11 4:28 AM, and...@torproject.org wrote: >>... >> https://svn.torproject.org/svn/torvm/trunk/doc/design.html. > > ... this statement is incorrect: > > "This is important in a Windows environment where capabilities like Linux(R) > netfilter or BSD(R) packet filter do not exist."
it is not as simple, but you could create the equivalent facilities on Windows. torvm is deprecated (an out of date proof of concept?) but this statement would be worth updating for someone with access to that repo. to clarify, to implement the desired owner / application based port, and protocol filtering, you would likely need to implement a shim with NDIS intermediate and filter driver interfaces as well as the newer WFP features if available to do what is needed on the intended XP through 7 systems. this also implies driver signing and the scrutiny / hurdles that involves for modern Windows 32 and 64bit kernels. if you only target windows 7 the built in filter facilities, while not equivalent on command line basis, are probably suitable. and WFP certainly is! this is a longer discussion, for someone interested. broken out to map the various old intermediate APIs and support, to the newer filter interfaces and advanced command line capabilities need to do full host transparent proxying without a guest or aliased interface (inline), and in tandom with one or more guest VMs to isolate Tor or its accompanying components. > ... But the OS interface > to do transparent proxying has been in NT for decades, first with TDI and > NDIS, now with WFP. transparent proxying to the host itself is technically different enough to matter between WFP and NDIS. that is, there is more to this than just intercept/forward, nor just port filtering or redirect. while there are features to do this on WFP (and to a lesser extent with NDIS) the command line capability and full host transparent proxy are still tricky (and worth breaking out into detail as mentioned above, if someone is interested.) > I also am confused by modern LibEvent performance and this comment: > > "For Windows platforms offloading the TCP session intensive Tor process to a > Linux guest with edge triggered IO can significantly improve the performance > of Tor and eliminate socket buffer problems." presume that this is in context of relying on poor socket style interfaces in Windows networking instead of high performance I/O completion ports and async networking. at the time of writing, Tor did not take full advantage of async I/O on Windows due to libevent limitations in the 1.x series. libevent 2.x has much improved Windows support. > ... I would have thought a single WFP (or TDI or NDIS) > driver would be improve the performance more than running a VM with a second > OS and using TAP to talk to the virtual OS Linux network. that would be ideal, but still much more work. Tor VM used existing WinPCAP and Tap32/64 drivers, there was zero kernel side driver development to make use of the existing transparent proxy facilities in linux. > Is the current Windows implementation of LibEvent still that > performance-challenged? I thought Nick and other [GSoC] LibEvent > contributers have improved LibEvent to be a "first class citizen" on > Windows, and have reasonably performance event implementation these years? yes. see above. Tor VM is nearly 3 years out of date at this point... _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
