In-Network Hashing

code status:

1. two level of NRS: LNRS, GNRS, corresponds to LNRS_daemon and GNRS_daemon. The client sends GNRS insert/lookup message to its LNRS server and then LNRS server will forward the message to GNRS. The client gets to know its LNRS server from a configuration file.

2. locator is made up of two parts: network address: local host GUID. Network address part is stored at GNRS and works as the inter-domain routing locator, while the local host GUID is stored at LNRS and works as the intra-domain routing locator.

3. each GUID mapping could have multiple NAs with TTL and weight attached. So the format of a GUID mapping looks like this: GUID: NA1, expiring timestamp weight; NA2, expiring timestamp weight;... (here, though the time field in insert/lookup message is TTL, the time field at the server is expiring timestamp. The server needs to do the translation. The advantage of such timing scheme is that it's not required that the whole system has the same clock.)

4. now the daemon uses a configation file (servers.lst) to know which servers are working as GNSR server. The servers.lst works as faked BGP table now. And for the hash function, it will return an index given GUID (supposed the index is i), then the ith server IP in the servers.lst will be chosen as the GNRS server for that GUID.

5. there are two sets of hashing functions that are implemented: the first hashing function directly returns with a server node IP address from the GUID. the other hashing function works in a consistent way with the GNRS paper: return an IP address hashed from GUID, then check the prefix table to get the corresponding AS number, and finally use another map function to map the AS number to a server node IP.

work need to do:

1. a client gbench used for generating insert/lookup message and receiving responses.

2. GUID caching

3. evaluation

3. no routing scheme, may need to adopt BGP later.

5. IP hole.