[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Getting 'Unreachable' Servers Onto The Network



On Thursday 28 February 2008 19:38:04 Robert Hogan wrote:
> Maybe it's a solution in search of a problem, maybe UPnP will sort most of
> this out, but assuming that the following problem is real and substantial:
>
> Problem: Restrictive local/remote firewalls and routers are preventing many
> willing candidates from becoming OR servers. UPnP can mitigate this problem
> if it is confined to a DSL router firewall (with UPnP enabled by the user)
> but it still leaves a substantial chunk of willing servers out there whose
> ORPort is not available to outside connection attempts. The Tor network is
> losing out on their bandwidth. At the moment we don't even know how many
> such 'candidate' servers there are.
>

>
> Major objections:
>
>  i. Thousands, millions of idle orconns! Uugh! It's an ugly thought I
> admit, but they're pretty cheap as far as I know. Would a server have any
> actual problem handling them?
>

The notion of connecting to *loads* of other servers is pretty daft. Perhaps a 
better way of doing it would be:

- Every published server accepts orconns from a maximum of N fallback servers.
- Every fallback server maintains N orconns with published servers.

When clients are building fallback circuits they simply request an unspecified 
fallback server for either the middleman or exit. The choice of server is 
left to the node constructing that leg of the circuit.

The choice of server is communicated to the client and the client verifies 
that a listed fallback server has been chosen. It would only use the same 
fallback server X number of times per fallback circuit, and never more than a 
specific number of times from the same published server for a defined period 
of time.

>  ii. [insert major anonymity problem here]

Which is probably where this comes in. The choice of fallback server is 
delegated to a published server but as long as the client is careful this 
shouldn't matter.


>
> This isn't the result of days of solemn reflection so feel free to kick me
> out of the park on it.


Attachment: signature.asc
Description: This is a digitally signed message part.