Menu
▾
▴
Re: [dcplusplus-devel] Question about DC++ development
|
From: Gavin S. <ga...@ho...> - 2012-01-20 19:10:59
|
I've never been totally convinced that the benefits of hashing outweigh the negatives in a LAN environment. - Transfer speeds tend to be quite high and bandwidth is free, so restarting a download isn't as expensive/painful as it is in a WAN. - You're more likely to actually know the person you're downloading from, so concerns about fakes are reduced. - Simultaneous multisource downloading can saturate the network with activity for no real benefit - you won't get the file any faster unless the source has abnormally slow disk drives. Of course, hashing in a LAN environment is still excellent for finding a new source when the one you had goes offline. Without hashing, if two sources of the same file name them at all differently, then a filename-based match will fail. If two files have different content but the same name, the match will incorrectly succeed. I think this could be worked around by the use of SCH EQ to find files of exactly the same size, and then prompting the user to select the best source by showing them a list of filenames to choose from. If you want to keep hashing, then prioritizing hashing based on what people want to download has problems. For one, the GET command with type=file requires that the "identifier must come from the namespace of the current session hash." This would mean knowing the identifier hash from either the file list or the RES of a search, but hashing won't complete quickly enough to respond to a search for all but the smallest of files, and the requested file may not have been hashed when the file list was built. I think, hashing or no hashing, you will require a new 'type' for the GET command that doesn't mind regular file names - you're kinda stuck with keeping the session hash because of the CID/PID, and keeping them is good because it helps identify mischievous impersonation (far too much of that used to happen on my LAN, and IPs could change). In conclusion, I think any LAN-version of DC++ should simply not hash files, and use a modified GET command for downloading. Downloading should be single-source unless the source goes offline, at which point the user should be prompted with any likely matches, which can then be semi-verified by grabbing a few thousand bytes before the resumption point. This is hacky, and where possible hashing does have serious benefits, but the start-up cost can be quite significant and impedes the fast availability of large shares. The download page for any LAN-version should state the key downsides of using it e.g. weak integrity checking. I've said many times on dcdev (under an alias) that DC++ should focus on what it does better than others, and LANs are a clear strength given the community-centric feature of chat being integrated into the server rather than managed by a separate IRC server. Regards, Gavin -----Original Message----- From: Jacek Sieka [mailto:arn...@gm...] Sent: Friday, 20 January 2012 9:58 PM To: Lewis Hosie Cc: Patches & development discussion Subject: Re: [dcplusplus-devel] Question about DC++ development Hi, I hope you don't mind be taking this question to the devel list.. In general, there were/are good reasons not to use filename based sharing and I don't see mainstream DC++ going back, specially not to downloading from unhashed sources. However, one way to supply "instant" sharing at the uploading end (which seems to be the actual functionality you're missing?) that could make it into the core would be to generate the hashes semi-lazily - i e allow search and browse by filename and somehow prioritize hash-building for files that are in someones download queue. Also, if you would like to make a lan-version of DC++, we would gladly accept any patches that would make maintaining your fork easier as long as they would make reasonable sense in the hash-only core. Regards, Jacek On Thu, Jan 19, 2012 at 2:19 PM, Lewis Hosie <lew...@gm...> wrote: > Fantastic, thanks for that Fredrik. > > Hi guys, > Over the last few years I've been attending LAN events in Melbourne, > Australia. I'm not sure how aware you are of this but pretty much > everyone around here uses DC++ (old versions of it) to share files at > LANs. The main reason for this is that few other filesharing programs > support organised downloading of entire folders, but can also share > tens of terabytes without spending days to weeks hashing (especially > when the LAN itself is shorter than the amount of time needed to hash). > > There have been a few attempts at original LAN-oriented filesharing > apps (D-LAN etc) and have also been a few attempts to get people to > switch to them (I even wrote a working demo of one myself), or to > switch to the latest version of DC++, but these have always met with > failure. The key problem I think is that nothing else has the > combination of the ability to share without hashing as well as > backwards compatibility with early versions of > DC++ on NMDC hubs. The main two versions which are used in this manner > DC++ are > .306 (AFAIK last version not to hash) and .674 (AFAIK last version to > load unhashed file lists), which of course are pretty damn old. > > There's also been a few attempts at building a version of DC++ that > doesn't need to hash (LANDC etc) that are based on hashing DC but with > hashing removed, making them incompatible with pretty much everything > except themselves. > > While undoubtedly these events should be switching to ADC and newer > versions of clients, and while purging unhashed and NMDC-based clients > from the internet has been a long painful process, it's pretty much > inevitable that a whole lot of people are going to stick with old > versions (or unsustainable forks of old versions) until there is a > solution that works with DC++ .306, works with newer versions, and allows instant sharing. > > Is the DC++ project as a whole entirely committed to never re-adding > support for these things? Would the project suffer from a new version > that allows downloading from (not necessarily uploading to) unhashed > sources and the ability to add unhashed files for LAN connections only? > > I've made a few experimental clients for various protocols, but they > would be entirely redundant if there was the possibility of DC++ > covering those bases. I'm willing to put some work into creating a > fork with these features if there's the possibility of reintegration into the mainstream client. > > Thanks, > Lewis Hosie > Developer at Prolapsoft > > On Thu, Jan 19, 2012 at 8:55 PM, Fredrik Ullner <ul...@gm...> wrote: >> >> Hi Lewis, >> >> I am no longer an active developer for DC++ (haven't been for some time). >> The main developers are Jacek Sieka and poy (CC:ed). They should be >> able to give you more information about where they want things to go with DC++. >> (It'd be nice if I were on a CC since I'm curious about what you >> want. :) ) >> >> If you have any particular question about the code or software, you >> can go to <https://launchpad.net/dcplusplus>. Also, you can go to the >> developers hub (via DC++) located at <adcs://hub.dcbase.org:16591>, >> where there are not only developers for DC++ but for other Direct Connect oriented software. >> >> On Thu, Jan 19, 2012 at 5:16 AM, Lewis Hosie <lew...@gm...> >> wrote: >>> >>> Hi there, >>> >>> I have a big question about both the application of DC++ and its >>> overall development direction. Before I explain it in full, I'd like >>> to know whether I'm asking the right person - are you one of the main developers of DC++? >>> Can you speak for the overall direction of the project? >>> >>> Thanks for any response, >>> Lewis Hosie >>> Developer at Prolapsoft >> >> >> >> >> -- >> Fredrik Ullner > > ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ dcplusplus-devel mailing list dcp...@li... https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel |
