On Fri, Mar 01, 2013 at 01:38:43PM +0200, Mihail Costea wrote:
On 1 March 2013 13:08, Antonio Quartulli ordex@autistici.org wrote:
On Fri, Mar 01, 2013 at 12:59:18PM +0200, Mihail Costea wrote:
Hi,
I've started implementing DAT for IPv6 and I have a few questions regarding the design. I've already implemented a snooping mechanism for Network Solicitation package, but now I have to add it to the ipv6 distributed table. I'm also a beginner in kernel programming so any help would be useful.
From what I've seen there is a lot of code in distributed-arp-table.c that could be used for ipv6 distributed table.
yeah, I think that the table handling and DHT primitives can be reused for IPv6 (they were designed on purpose).
A problem in using that code, from what I've seen, is the fact that <struct batadv_dat_entry > has a field for ip with only 32 bits (__be32).
Yes, here a way to generalise the structure is needed.
So I was thinking to make it more general by:
- transforming that into a pointer (unsigned char *ip) and add a
field size which will represent the total size of the ip. The ip itself would be allocated dynamically. 2. use a union with both _be32 / struct in6_addr. In this case the problem is that if we use ipv4 then all the other space for struct in6_addr would be wasted.
correct. and for point 2) I think we waste a not negligible amount of memory..
The second problem from what I've seen in the code is that the batadv_priv->dat field is hardcoded. For ipv6 we would need a new field to memorize the table, but I don't think it's a really hard problem to solve in order to make it general.
I did not get the problem with the dat field? Can't you use the same table to store both IPv4 and IPv6? The DHT is made to store general data, so I think (with the suggestions you wrote above) that you should be able to use one table only.
I think it can be reuse. If I understood well the DHT has buckets for each entry, so it shouldn't be a problem if the IPv6 hash collides with the IPv4 hash.
yeah in general hash collisions are not a problem (well it is better to reduce them in order to provide a better distribution of the data).
I just thought that they should be separated because because they are different concepts.
yes, but in the end they are still separated at the logical level (the data size will make the difference). Maybe you can add a "type" field on the bucket? In this way we can easily differentiate one data type from another (this maybe helpful for future use of the DHT too) instead of replying only on the "addr_size" field.
This makes it a lot more easier :).
Yeah :)
Cheers,