DC++

I posted details and source code for the huffman scheme used in .dclst files a while ago. See here.

Your code generates the same keys as mine, and I get the same small errors, I really wonder what the reason could be, especially if it works on your pc... In that case, it's probably a problem with your character encoding. You should be using the default encoding, ie. System.Text.Encoding.Default, ...

Mine. Tested and it works. /// <summary> /// Computes the $Key respnse to a given $Lock command. /// </summary> /// <param name="lockStr">The Lock string in the middle of "$Lock (.*) Pk=".</param> /// <param name="xorKey">0x05 for a connection from a client to a hub, /// or (localPort+(localPort>>8)...

See this thread: Upcoming: ZLib block compression.

Great! I was sure I had tested them and they worked, but I wasn't sure because both those files were restored from an old backup (long story).

arnetheduck wrote:heh, gumboot, a bit more and it should be your name on that client =)

LOL

You're right. In fact, I am hereby making that a requirement of using my code: you have to call your app "Gumboot's DC client".

Well OK then. Same priviso as above; mail me if you find any bugs. /// <summary> /// Class for compressing NMDC file lists. /// </summary> /// <remarks> /// Written by Paul Bartrum ([email protected].com) /// </remarks> public class NMDCHuffmanCompressor { class HuffmanCompressionNode...

andlju wrote:Oh.. and by the way, if someone has an encoder as well, there is always room for another hero..

Well, if you can tell me you've tested my decoder and it works, then I'll post my huffman encoder. (Just trying to get some free testing )

I guess then I'll be a hero twice over!

Since you asked so nicely, here's my huffman decoder. It's written in C# and IIRC has been tested and verified as working. YMMV. If you find any bugs please contact me. /// <summary> /// Class for decoding NMDC file lists (of the form MyList.DcLst). /// Encoding is not supported. /// </summa...

The problem is definately the character encoding. You may not realize this, but you are doing at least 2 character encoding conversions. 1: UTF8.GetBytes() (converting the lock string to a byte array) 2: Your network send code (converting the key string to a byte array) You need to use the character...

zhaPP wrote:do you just huffman-compress the raw filelist and add the header in the beginning?

Yes, that is exactly what you do.

You know huffman coding? Here are the details for the neomodus variant: byte offset / description 0 = "HE3" (magic bytes) 3 = 13 4 = checksum (XOR of every byte in the uncompressed file) 5 = length of uncompressed file 9 = number of entries in following table 11 = entry 1 [uncompressed byte, compres...

Good job!

I hate to sound like I'm complaining, but the docs would be much easier to view if you put them on the web server individually (ie. not zipped or rar'ed) and put up a contents page that linked to each page. Or even better (IMHO) combine it all into one page with links at the top.

Is there realy a need to provied the hase valut in the search? Is it not easier to transfer the hash in the Client to Client protocol? If clients don't send the hash value in search results then there is no (practical) way to automatically group search results, ala KaZaA, eDonkey, etc. This is a de...

Does client->client lock2key algoritm is the same as in client->hub ? (still xor byte = 5 ?) Yes. I maybe mistaken but I belive there is no direct client to client protocal it all goes through the hub You're mistaken. Just after connecting to another client (for downloading) the one downloading use...

Well, it would take a few hours, but since hashes would be stored (either in a database, or using an NTFS alternate file stream) they would only need to be calculated once. I don't see why you would ever need to rehash all your shared files.

Nice idea! I wonder, though, why so many search requests have extensions? I know I don't include the extension in searches I make... Could it be the "Automatically search for alternates" feature in DC++?

No, that's the standard port used when connecting to a hub. The standard port for initiating p2p file transfers *was* 412, but with the latest versions of DC++ it's now random.

IMHO, if we ever want the ease-of-use features of, say, KaZaA in DC, we need to implement file hashes. The following features spring to mind: * Automatic grouping of search results. * Automatic finding of new sources. * Working hyperlinks to DC files (rather than just hubs). * Automatic redownloadin...

OK, I think most people here agree we should add file hashing to the DC protocol, especially given that the vast majority of p2p systems have it already. Note that none of the proposed solutions require any changes to the hub. We could do a lot better if we mandated changes to the hub, but for pract...

FYI, you seem to be missing a close bracket ')' in the $SR description.

Excellent! This is just what we need!

One thing that occurs to me though is how do the clients know that this extension is available? Perhaps you should include the QuickList spec as part of your document (I assume Nev won't mind): http://forum.dcstats.net/showthread.php?s=&threadid=802