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
Attachment:
pgpXVM0Ghp8L0.pgp
Description: PGP signature