Thanks for your feedback!
On Tue, Dec 6, 2011 at 1:45 AM, Linus Nordberg linus@nordberg.se wrote:
Aaron aagbsn@extc.org wrote Mon, 5 Dec 2011 16:38:49 -0800:
| IPv6 Addresses are stored as strings, the same way as IPv4 addresses. | #XXX: is this better than using the ipaddr.IPAddress class?
What kind of database is this? If it is possible to use the rest of the database for a program written in a language without (the exact same implementation of) this particular version of Python ipaddr a string representation might have a value. If not, for easier debugging? Unclear to me.
The backend database (sqlite3) will still store the addresses as strings. Once a Bridge object is constructed (loaded from the database or from a bridge descriptor) - should the address representation (e.g. Bridge.ip or Bridge.or-addresses[n]) continue to be stored as a string or the more convenient ipaddr.IPAddress class? ipaddr.IPAddress.__str__() will return the string representation (for example, when storing Bridges to the database).
The advantage of using ipaddr is that class(Bridge.ip) will return either ipaddr.IPv4Address or ipaddr.IPv6Address. It's convenient, works, and already written.
The disadvantage is that for every Bridge object, at least one ipaddr.IPAddress object will be created. The overhead (if any, depending on how compact the packed addresses are and python object size) may not significant (depending on your perspective of significant) but it is worth thinking about as we want BridgeDB to scale to 10k bridges or more.
The alternative approach is to always store addresses as strings and detect the address class when necessary (e.g. sorting Bridges). If BridgeDB needs to sort or filter Bridges frequently then this approach could present performance issues.
I don't want to optimize prematurely either. Either approach should be replaceable without too much effort.
| Parameters may be repeated to select multiple classes, e.g. | | q=ipv4&q=ipv6 - Request both IPv4 and IPv6 bridges. | | When no parameters are set, by default BridgeDB must return addresses | of the same class as the client. This default may promote IPv6 use | where possible.
This might cause confusion in cases where the equipment used for getting a bridge address is not the same as the equipment which is going to use it. Very few computer users know if they're using IPv4 or IPv6.
Is it worth it?
The scenario where this hurts us is when a user with IPv6 who needs IPv4 bridges lands on the https://bridgesv6.tpo page, and doesn't click the link for IPv4 bridges. That scenario likely leads to a support request, but I suspect it will not be a very common one -- or at least not until IPv6 is adopted more widely. Our strategy in the future should change as we get feedback.
For example, in a 'mostly-ipv6' world, perhaps https://bridges.tpo will be dual-stack, and the https://bridgesv4.tpo page will give out ipv4 bridges. As long as we have the flexibility to change our approach, we can make the best decision when we have better data about the types of requests https://bridges.tpo sees
The selectors described above are proposed because some clients may not set a 'Host' header, and adding support for parameters in the request string is easy. If a client does not specify anything (Host header, or query string) then BridgeDB could instead default to giving out IPv4 addresses. We want people to use IPv6 (right?) so promoting it to users who can take advantage of it makes sense to me.
| | How does someone end up at bridgesv6.torproject.org? | | BridgeDB should include a message at the end of its' response. | e.g. | | "Get IPv4 bridges https://bridges.torproject.org" | "Get IPv6 bridges from https://bridgesv6.torproject.org" | "You must have IPv6 for these bridges to work." | #XXX: will users understand what this means?
I'd like to stress the case where a user fetches a bridge address on a computer which is not the consumer(s) of the address and suggest "These bridges will work only on computers with functional IPv6." or similar.
I agree. I do think that the warning string is a good first approach to reducing the confusion.
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev