decoding a uTorrent dht.dat and resume.dat file

[nebulator]

Is the format/specification of the dht.dat and resume.dat files published anywhere?

I am trying to look at the contents; and having opened dht.dat in the bencode-editor-0.7, I understand the various bit but i am struggling to suss the nodes bit. it starts 0x13 and thus is initially interpreted as binary, but the contents dont look it.

The editor does a cool job on the resume.dat, but I am not sure what the values are in there like 'trackermode', 'seedtime' (ie from when), dht (i),

Does anyone know the structure of this element of the file? Is it based upon or similar to the transmission dht spec, would reading that source assist me?

Grateful for any help. cheers.

Nebs

[Ultima]

Don't know for sure, but I'd imagine it's just storing a bunch of raw IP:port combinations as 6-byte values (4 bytes for 32-bit IPv4 address, 2 bytes for 16-bit port value).

No idea what Transmission DHT spec you're talking about. Transmission doesn't have its own DHT -- it uses mainline DHT. And no, reading another client's source code wouldn't help you figure out how µTorrent stores data.

[nebulator]

Ultima,

Cheers, that worked!

I was able to sort out the various IP addresses and ports. Do you know if the addresses are stored in the order they connected to the system, ie is the first address in the resume.dat and the dht.dat (I was able to decode some of it), the first machine the system connected to? I ask as we are using uTorrent to move some big files (film studio stuff) about on our uni network, but one of the machines is always last (ie they take 25 minutes and this one machine takes hours), and we are trying to work out why. The are all the same build and are on the same subnet, we ahve done the windows reboot and reinstall stuff to no avail.

99% of the configs are the same, but the peer list is different for this system. We wondered if it it being shunned and thus is picking up the other peers later and therefore did the order matter - I would assume they were written in the order they were put on the stack in memory, but it depends how often they are poped of different stacks before being written as the correct order - if any exists).

Also does anyone know how often the resume.dat was updated. I know it is read on startup and is written on prog close, but it must be updated in between - our systems are up and seeding for weeks :-).

Grateful for any thoughts.

Nebs

[Ultima]

Also does anyone know how often the resume.dat was updated.

I don't recall exactly, but I believe it's something on the order of seconds (between 10 and 30 seconds, I think).

As for your other problem, that I really don't know, but I seriously doubt the order in which addresses are stored in dht.dat would impact it so greatly. I'd chalk it up to some other issue (misconfiguration, or maybe faulty hardware somewhere along the way). Is the machine just downloading more slowly?