Odd testing results for 6th stage

In this stage, I think I used the hash calculation correctly. However, when I try to test it, I get errors saying that the hash is not correct, even though it is. In another test, the hash is not correct.

correct hash:

[tester::#RB2] Running tests for Stage #RB2 (Calculate info hash)
[tester::#RB2] Running ./your_bittorrent.sh info /tmp/torrents245747744/itsworking.gif.torrent
[your_program] Tracker URL: http://bittorrent-test-tracker.codecrafters.io/announce
[your_program] Length: 2549700
[your_program] Info hash: 70edcac2611a8829ebf467a6849f5d8408d9d8f4
[tester::#RB2] Expected stdout to contain "Info Hash: 70edcac2611a8829ebf467a6849f5d8408d9d8f4", got: "Tracker URL: http://bittorrent-test-tracker.codecrafters.io/announce\nLength: 2549700\nInfo hash: 70edcac2611a8829ebf467a6849f5d8408d9d8f4\n"
[tester::#RB2] Test failed

incorrect hash:

[tester::#RB2] Running tests for Stage #RB2 (Calculate info hash)
[tester::#RB2] Running ./your_bittorrent.sh info /tmp/torrents2180998007/codercat.gif.torrent
[your_program] Tracker URL: http://bittorrent-test-tracker.codecrafters.io/announce
[your_program] Length: 2994120
[your_program] Info hash: b2e418942622262a433ceda7b2e6e154a112318e
[tester::#RB2] Expected stdout to contain "Info Hash: c77829d2a77d6516f88cd7a3de1a26abcbfab0db", got: "Tracker URL: http://bittorrent-test-tracker.codecrafters.io/announce\nLength: 2994120\nInfo hash: b2e418942622262a433ceda7b2e6e154a112318e\n"
[tester::#RB2] Test failed

edit: forgot to mention that the info hash for the sample.torrent is correct. i checked with the example on the website’s instructions.

Hi there!

For the first case, I think it’s just a case of capitalization (expected: “Info Hash”, actual: “Info hash”).

For the second case, one common issue we’ve observed is related to sorting keys: if the keys in the dictionary aren’t sorted before encoding, you’ll end up with a different hash. Could you confirm whether this is the case?

1 Like

yes you are right about the first case.

about the second case, i think this may be the problem. i wasn’t aware the use of sorting.
i checked the specification and didn’t find anything about sorting the keys.

can you please provide sources so i can reference to?

thank you very much!

Yep! Here it is:

https://wiki.theory.org/BitTorrentSpecification

1 Like

Hey Rohitpaulk,

I appreciate your answer, but even though the dictionary is sorted, it still doesn’t give the correct hash. I’m including the logs and the order of the dictionary here to show you that, although the order is correct, the hash isn’t, even though it passed other tests.

[tester::#RB2] Running ./your_bittorrent.sh info /tmp/torrents132665628/codercat.gif.torrent
[your_program] {"length": 2994120, "name": "codercat.gif", "piece length": 262144, "pieces": "<40����c�~��%�jиQ�.��7?�g�DB�VɊ"}
[your_program] Tracker URL: http://bittorrent-test-tracker.codecrafters.io/announce
[your_program] Length: 2994120
[your_program] Info Hash: b2e418942622262a433ceda7b2e6e154a112318e
[tester::#RB2] Expected stdout to contain "Info Hash: c77829d2a77d6516f88cd7a3de1a26abcbfab0db", got: "{\"length\": 2994120, \"name\": \"codercat.gif\", \"piece length\": 262144, \"pieces\": \"<40\x9f\xae\xbf\x01\xe4\x9c\x0fc\xc9\v~\xdc\xc2%\x9bjиQ\x9b.\xa9\xbb7?\xf5g\xf6DB\x81VɊ\x1d\"}\nTracker URL: http://bittorrent-test-tracker.codecrafters.io/announce\nLength: 2994120\nInfo Hash: b2e418942622262a433ceda7b2e6e154a112318e\n"
[tester::#RB2] Test failed

the order “length”, “name”, “piece length”, “pieces” is the correct order as raw string.

  • “length”

  • l: 108

  • e: 101

  • n: 110

  • g: 103

  • t: 116

  • h: 104

  • “name”

  • n: 110

  • a: 97

  • m: 109

  • e: 101

  • “piece length”

  • p: 112

  • i: 105

  • e: 101

  • c: 99

  • e: 101

  • (space): 32

  • l: 108

  • e: 101

  • n: 110

  • g: 103

  • t: 116

  • h: 104

  • “pieces”

  • p: 112

  • i: 105

  • e: 101

  • c: 99

  • e: 101

  • s: 115

i even included functions to ensure that the strings are sorted:

// Comparison function to be used with qsort
int compare_keyval_pairs(const void *a, const void *b) {
KeyValPair *pairA = (KeyValPair *)a;
KeyValPair *pairB = (KeyValPair *)b;
return strcmp(pairA->key, pairB->key);
}

// Function to sort a dictionary by its keys
void sort_dict(KeyValPair *dict, size_t size) {
qsort(dict, size, sizeof(KeyValPair), compare_keyval_pairs);
}

am i missing somthing here?

Ah, okay so sorting definitely isn’t the issue here then.

@hipsteromer here are the three files we use for testing: bittorrent-tester/torrents at main · codecrafters-io/bittorrent-tester · GitHub.

Can you try running your code against these locally, and see if the hashes match what you get by uploading the same files here? https://torrent.parts/

For context, hash mismatch cases are really hard to help out with since we can’t reverse the hash to figure out what the bug with the input is. The best we can do is share common mistakes + prove that the hash is indeed wrong.

Created this issue to fix the first case you mentioned (case mismatch):

ok i checked locally for each of the files. i got all of them correct, including the sample.torrent, but i got the codercat.gif.torrent wrong.

also, i noticed that this file (codercat.torrent) is the only one that i couldn’t view/open from github, vscode editor. or any other text editor.

feel free to check my github repo: GitHub - hipsteromer/bitTorrent-client: project 1

Aha, nice find. Cool! So it looks like you have a file to locally test with - the fact that it doesn’t render on GitHub likely means that it contains a lot of binary content compared to the others.

Please let us know if you figure out what the bug was here!

1 Like

FINALLY A SOULTION!!!
the problem was that in that file were a \x00 character, which most of the string.h functions, consider this EOF but in that case it wasn’t, like strlen(), strcat() and so on.

I stopped using functions like those started safely and carfully handle binary strings.

1 Like

Nice find! Can imagine how hard this was to track down :slightly_smiling_face:

This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.