Okay, if non exist then you send the quality of successor.

The second line ensures that even if the finger table entries are wrong,

then [INAUDIBLE] present, then as long as the successors

are correct you end up routing the query to the correct server eventually.

It might take a long time.

It might take n hops in the worst case, but

you end up routing it to the right way.

So let's ignore that same part for now but

essentially at N80 remember that the finer table entries an 96, 112, and 16.

So the one among them that is the farthest to the right,

the farthest away clockwise from N80 that is still to the left of 42 is 16.

That's why N80 will forward the query to N16.

When N16 received this, it does likewise.

It calculates among it's neighbors which are its successors and

finger table entries, which is, the most to right, but still to the left of 42.

And you'll notice that 16 will have 32 as a finger table

entry because essentially, 16 plus 2 power of 4 is 32.

But 16 plus 2 power 5 is 16 plus 32 that's 48 which means that the fifth,

the next finger table entry after 32 at 16 is N80,

which means that 16 does not even know about N45's existence.

And so 16 has only two choices, 32 or 80 to forward the 32 and since

32 is to the left or counterclockwise of 42, it forwards it to 32.

32 tries to do similarly but

it doesn't have a neighbor that is to the left of 42 so it simply forwards it to its

successor and that's where the second line comes into play.

And that makes its way to 45.

Whenever a node receives a query in relation to this algorithm, it also checks

its local files to see if any of those files match, and in this case, 45 matches.

And it can respond back directly to anything with the response.

Now in this case, I've drawn three arrows here.

Each of these are the hops that the query takes.

These hops are essentially RPCs or remote procedure calls.

This is a well known abstraction in discriminate systems.

So I claim that this algorithm takes O(log(N)) time.