How should a 20-byte UDP string be transmitted in big-endian format?

Question

bittorrent

Hello everyone, for a long time I tried to figure out why my implementation of announce to the tracker does not receive the necessary response, I decided to sniff utorrent and compare each element from their request with my own. In general, I quickly found out that the only problem is that we have different info_hash:
my info_hash: "v\201\327|\r\270\265\227e\254\216[\275\316[\262\245 \264g\006"
utorrent info_hash: "|\327\201v\227\265\270\r[\216\254e\262[ν\006g\264\245"
Obviously Endianness is the culprit, and indeed, splitting my string into an array of 5 4-byte numbers, and then changing them to endian, I got a string identical to utorrent! It should be noted that all protocol data must be transmitted in the Big-endian format.
But, in the specifications that I found, it is explicitly stated that this is either a 20-byte string or a 20-byte int8_t array:
www.bittorrent.org/beps/bep_0015.html && https://www.libtorrent.org/udp_tracker_protocol.html (see IPv4 announce request).
Please suggest, wouldn't a one-byte string look the same in any form of endian? Can you help me figure out why it is necessary to change the byte order here (all the torrent files that I tried to announce from the tracker gave invalid data until I accepted this info_hash order)?

Answer 1

Please suggest, wouldn't a one-byte string look the same in any form of endian?

For a byte array, endianness is irrelevant. If it's really an array of bytes.
Info_hash seems to be not just an array of bytes, but has an internal structure. According to your links, this information is not available, apparently, we need to dig deeper.
So do the conversion to BE.