Tor Ipv6-Patch

[Nick Mathewson]

On Tue, Dec 04, 2007 at 08:03:50AM -0500, Michael G. Reed wrote:
> On Tue, 4 Dec 2007, Marcus Wolschon - Wolschon Softwaredesign wrote:
> |> >  - You're right that the preferred way to store addresses that could be
> |> >    either IPv4 or IPv6 is indeed with tor_addr_t.  (Thanks for the
> |> >    reminder, BTW: I fixed tor_addr_t to be a tagged union of in_addr and
> |> >    in6_addr, not of sockaddr_in and sockaddr_in6.)
> |> 
> |> do you want to do the refactoring to use tor_address_t or shall I?
> |> So we need a pair of tor_address_t and int socket_family. Wouldn't it
> |> be better to have the socket_family in a struct with the tor_address_t
> |> - -union? That way it would probably be a drop-in -replacement for the
> |> 32bit-addresses.

Check out how the code for tor_addr_t is now; it's about what you say:
It's a struct with a family and a union of in_addr and in6_addr.
("Tagged union" in this case means "union with a field that tells you
which case of the union a particular item is.)

(Also, you keep saying "tor_address_t" instead of "tor_addr_t".  Are you
looking at another struct somewhere with a different name?)

> This is exactly why multi-protocol developers normally use
> sockaddr_storage to define the space for an address they do not know
> the type of in advance and then rely on the sa_family field to
> differentiate.  sockaddr_storage is guaranteed to be large enough to
> hold the largest supported address type in the system (not
> efficient/desirable/usable for on-the-wire, but is best used in
> application processing).

Alas, we need lots of these: a rough estimage is at least 40K [*] on a
busy server.  Sockaddr_storage is about 128 bytes on most platforms
I've encountered, whereas we only need ~16 bytes for an in6_addr.
(sockaddr_in6 is only ~~28 bytes).  I know Tor is already a bit of a
memory hog, but adding another 4MB to the process size for the unused
portion of all the sockaddr_storages rubs me the wrong way.

Yrs,
-- 
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20071205/8fb70d5d/attachment.pgp>