CSE 124
2017 December 1: An explanation of Chord finger tables

Today’s in-class exercise wasn’t the most clear explanation of building “finger tables” (or routing tables) for Chord nodes. In this blog post, I’m hoping to provide a clearer set of instructions for building these data structures.

# The N=16 (4-bit) Chord ring

To ground our discussion, consider this N=16 (4-bit) chord ring. We’re going to visualize the 16-element keyspace as a circle, as shown.

# Adding servers to our network

Now, imagine that we have a set of servers, with associated hash values:

• www2 [0]
• mail [9]
• www [D]

# The finger table

Because we have a 4-bit (N=16) keyspace, each of the servers in our network is going to have a 4-row finger table (a 32-node network would have five rows, since 2^5 = 32). The table has this structure:

Start Interval succ

OK, let’s start filling it in. Recall that each row in our table is going to get us a power-of-two distance around the circle. If we’re node N, then the table should look like this:

Start Interval succ
N+1
N+2
N+4
N+8

In particular, node www2 (with ID 0) would have:

Start Interval succ
1
2
4
8

Whereas node mail (with ID 9) would have:

Start Interval succ
10
11
13
1

# Filling in the intervals

We are next going to fill in the second column. This column is simply a range representing the “gap” between each row. The start ID is included in the range, but the end ID isn’t. If we’re node N, then the table should look like this:

Start Interval succ
N+1 [N+1, N+2)
N+2 [N+2, N+4)
N+4 [N+4, N+8)
N+8 [N+8, N+16)

In particular, node www2 (with ID 0) would have:

Start Interval succ
1 [1,2)
2 [2,4)
4 [4,8)
8 [8,0)

Whereas node mail (with ID 9) would have:

Start Interval succ
10 [10,11)
11 [11,13)
13 [13,1)
1 [1,9)

# Setting the successor fields

This is perhaps where today’s discussion went off the rails a bit. To set the entries in the last column, we go through each row, and we look at the left-most side of the interval provided. From that point, we go around the ring clockwise until we find a server–that is the server that is responsible for that portion of the keyspace.

In particular, node www2 (with ID 0) would have:

Start Interval succ
8 [8,0) mail

Whereas node mail (with ID 9) would have:

Start Interval succ
10 [10,11) www
11 [11,13) www
13 [13,1) www
Given we’ve now built up these finger table, we can examine them to figure out how requests would be routed in this network. For example, from `www2`, to lookup a key with ID A, we’d look in `www2`’s finger table to find the row covering the region including A. That’s the last row, with successor `mail`. So we’d forward the request to `mail`.
Now, `mail` has to continue the lookup. For `mail` to lookup key A, it looks in its finger table, and sees that the interval that includes A is the first row. It looks at the successor entry in that row and sees that `www` is responsible for key A. It forwards the request to `www`, which has the data, and now the lookup is complete.
The complete path is `www2` -> `mail` -> `www`