Time for some real questions (Path lines)

[Matt / Brian]

Explain the [path] section of the RESULT message a little bit more. We wonder how we can affect it, how we pass it on to others, what is it exactly, in what way can we modify it, etc. Are path numbers added to the front or the back, etc. again.

Are there negative search ids?

What is the port number after JOIN meant to be used for?


That's all for now.

[Paco103]

Explain the [path] section of the RESULT message a little bit more. We wonder how we can affect it, how we pass it on to others, what is it exactly, in what way can we modify it, etc. Are path numbers added to the front or the back, etc. again.

The path is used to identify the path to the host with the file in the specified result. This is used to prevent un-necessary flooding, as well as preventing a file request being fulfilled by more than one host, although this can be done and controlled client side through proper manipulation of the GET command.

The path is built from right to left, which means they are added/removed at the front/left. Basically, the path ID means nothing to anybody on the network except the node that placed it. The path is just a list of unique identifiers for neighbors, without having to reveal identifying IP addresses.

Using the diagram attached to this message, imagine that A does a search for a file, let's just say "diagram.png" - which translated to regex would be "diagram\.png". Let's say that C has the file to offer. B,D,G, and H are all in the paths to C, but none of these nodes have the file, so the query is passed on with no result is immediately returned. Let's say that the path through B and D is the fastest path, so C receeives the request, and enters it into the active search table. C then fulfills the request with the message

RESULT

12345678
diagram\.png
8425
diagram.png
*

when D receives this result, D adds its local ID number for C, which is the node it received the result from. D then fulfills the request with the message

RESULT
4
12345678
diagram\.png
8425
diagram.png
*

B then receives this result from D, and adds its local ID for D. B then fulfills the request to it's requestor, A, with the following message

RESULT
8 4
12345678
diagram\.png
8425
diagram.png
*

A then receives the result it was looking for. By having the path "8 4" it knows nothing, however if it chooses to select this file from the options, when the GET request is built, this path is copied exactly. Since A knows it received this result from B, then obviously this was the fastest path to the file, so most likely it is the best path to request/receive the file, and it does not have to flood the network. It sends the get message to A with this path. B does not have to remember anything after the initial search, because most results will never be requested. When the get messages is received with the path, B then looks at the path, sees 8, looks up which of it's neighbors is represented by 8, and sends the message ONLY to this neighbor, and removes the number 8 from the list, leaving 4 as the only number in the path list. D then sees the 4, removes it, and sends the request on to C. C is then at the end of the list. Even if C is not at the end of the list, C has the requested file, so therefore MUST fulfil the request and cease propogation of the request.

Are there negative search ids?

This is a good question not specified in the spec, so thanks for pointing that out. As far as I know, most languages are default to a signed integer representation, so for ease of use I think using signed (with negatives) would be the best option. If you have an opinion about using unsigned integers, let us know, as it really doesn't matter in the protocol as long as it is known how to read and write it.

What is the port number after JOIN meant to be used for?

This is the port that the joining peer will be listening on for new connections. All incoming connections will be directed to this port. We've declared the default as 46505, however it really doesn't matter as long as other peers know what port is open for connections.

[Brian]

Ok, that all makes sense, but i have one question/suggestion. In your example, when C returns the result, it returns an empty path of, i guess a space or a null, not quite sure what it is. Would it not be easier to use some predefined number to reference yourself. Say, -1? That would allow the result string from C to match the spec result string so parsing would not have to change just for this one case. I guess this could be at our discretion, just want to make sure it wouldn't screw up anything else.

[Paco103]

Actually, that is entirely up to you as the client developer, since anything at your stage is for your reference only. The initial idea would have been just for an empty line (double new line after the RESULT line). However, if you wish to use your own coding, you may do that at your stage, as long as it does not interfere with parsing for other nodes. Since you are required to fulfil a received request even if you are not the last on the path, you may fill in anything you wish after your stage.