Problems running TOR for an extended period

[Jan Danielsson]

Nick Mathewson wrote:
>  [...]
>>    I'd rather like to find a real solution to the problem. Mainly,
>> getting a working gethostbyname_r(). Btw.. What is the origin of
>> gethostbyname_r()? Does it exist in all common/mainstream unicies?
> 
> Pretty much, except for the (I hope you'll forgive the term) less
> popular BSDs.

   No offense taken. However, the wiki I was pointer to earlier in this
thread is a bit to flammable for my tastes. From
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS:

   "[---] If you want to run a Tor server, we recommend you upgrade to a
better OS."

   Although this wiki is linked to from the TOR site, I am unsure if it
is an official TOR wiki, so this may be off-topic. I am also not sure if
the quote above is meant to say "[...] a better OS [for running a TOR
server]" or "[...] a better OS [period!]". If the latter is intended, I
suggest someone change it, because I don't feel that a TOR wiki is the
place for OS advocacy.

   Also, the statement is pointless in the sense that I highly doubt
that many users are about to switch operating system just to run TOR. I
may be wrong, but I know I certainly wouldn't -- even though I very much
am a supporter of what TOR is trying to accomplish.

   Anyway, even if OS advocacy wasn't intended, it's still pretty
flammable, imho. It would be better to mention that in NetBSD-current,
the gethostbyname_r() problems should be fixed. Or mention other
possible future directions which may work around such problems, and ask
for help from the BSD community.

> OpenBSD claims to have a gethostbyname_r, but it is
> lying: it just #defines gethostbyname_r to gethostbyname.  (This is
> the moral equivalent of keeping your rat poison in a jar labeled
> "cookies".)

   I know.. I have used API:s which I though were reentrant and mt-safe
but turned out not to be. It was an "interesting" exercise, as in "what
an interesting brain tumor you have". But in my case it wasn't
mislabeled; it was my own fault for not reading the document
introduction properly.

>>    As a side note, I don't understand why the calls to gethostbyname()
>> can't be mutex'd on BSD systems, rather than just switching over to an
>> all fork'd design. Are there other calls which are affected as well?
> 
> We _could_ go multithreaded and make it block, but performance on exit
> nodes would suck.  When two users wanted to make exit connections at
> the same time, one wouldn't start a DNS lookup until the other was
> done.  Also, an attacker could shut down all DNS requests just by
> making requests that would take a long time to complete.

   Ah, obviously. I never even thought of DNS lookups as being slow. :-/

> Right now, we're trying a different approach.  In version 0.1.2.x,
> we're trying an approach where we add a built-in async DNS resolver to
> Tor and don't use the platform DNS resolver at all: this way, we don't
> need to be multithreaded.  Right now, it seems to have a bug that
> creates a periodic segfault, but watch this space: I hope we'll get it
> straightened out soon.

   Oh, so the actual code (+ bug) is already there? Neat. I'll take a
look. Is a new release, with built in DNS resolver, planned for the near
future?


-- 
Kind regards,
Jan Danielsson


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 186 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060717/4125214a/attachment.pgp>