Blog Topic Suggestion Box
While I’ve been managing this Blog for some time (and the previous two as well), I’ve had little to no requests for post-topics.
While my e-mail, and Todd’s, and arne’s, and… is shown here and in other places, I guess people are hesitant to send a mail.
So, feel free to post here in this post if you want me or anyone else to talk about a certain topic. Or explain a certain feature. Or explain a particular bug. Or…
Please note that it’s very difficult for us to answer questions about a particular modification of DC++ or even a different client. (To increase the chances of us talking about a feature in another mod/client, have the feature/question be generalized.)
(Of course, browse the blog or FAQ first. Your topic may have already been discussed.)
If you’d like to suggest a feature for DC++, go to https://answers.launchpad.net/dcplusplus.
Direct Connect: Just These Guys, Ya Know? 
One of the things I really loathe are hit-n-run leechers. These people hop into a hub for just long enough to snag what they want, then disappear. I’ve been noodling around with techniques to foil this, and I think this may work …
What are the chances of implementing an optional points system in DC++ ? It would work more or less like this :
1) Every user of a hub earns points for every hour (or whatever timeunit) they are online.
2) Every user earns points for files that upload to other users. This is a combination of the points value of the file plus a modifier based on the upload speed. Faster = more points.
3) Downloading files costs points.
The point (hah) of all this is to encourage users to stay in the hub.
As userA downloads from userB, every n bytes both users report to the hub how much and at what speed has been downloaded. The hub updates the user’s points accounts, using userA’s reported speed for calculations (to prevent rate spoofing). We don’t want userB reporting that he sent the data at 600mb/s …
As time goes by, points are added to each user’s points account.
When userA wants to download a file from userB, userB queries the hub to see if userA has enough points. If so, the download progresses. Every n bytes or points, userB queries the hub again to make sure userA still has enough in the account.
JC
panalog9, we’ve discussed similar systems in the past on our forum. (Which is offline for the foreseeable future.) We’ve used various terms when discussing it, such as reputation system and credit system. Generally the discussion focused on contribution to other users in the form of uploads, and some of the schemes we proposed took inspiration from eMule’s credit system and secure ID. The discussions tapered off before the introduction of ADC, so I’m not sure how that would change schemes. Part of the problem is that the reputation system almost mandates a strict upload queue (otherwise, what are you really offering). For a long time, that was a feature that arnetheduck said he wouldn’t include in DC++.
There were some concerns, which you’ve included in your suggestion. One was that we didn’t want to penalize people with slow connections – overall contribution seems more important than speed, unless you’re on a fast connection and are one of those who would benefit from such a bias in the algorithm. Another concern was promoting good behavior instead of punishing bad behavior; the suggestion was to push people with good “karma” though the upload queue faster than people with no history. The other, which has become a bigger issue since then, is centralization. How much do you trust the hub? Do you want it to know who you’re downloading from, when, and how fast? Do you trust the hub to report accurately?
If you want to discuss this further, you can bring it up on the ADC “DCDev Public” hub, where many of us hang out. And feel free to put it into the feature request tracker at http://dcpp.net/bugzilla/ once it comes back up.
This page is technically for blog topics. ;-) (I’ve updated references to minimize further confusion.)
man…
this might sound stupid to you guys..
but i’ve had enough headaches already..
i been looking for a week for a solution.. and i just cant find one..
my dc++ 0.699 keeps crashing and crashing…
i dont know what to do..
i try to get on the bugzilla stuff.. and its not there..
plz im i beg for help.. pleasee..
my email is diber69@hotmail.com
one more time please guys..
Bugzilla is hosted on dcpp.net, which I’ve posted about lately as being down. Contact me via email with your exceptioninfo.txt, and if I know the cause of the crash, I’ll let you know how to stop it.
Todd – thanks for the quck reply. I understand the concerns you raised there. Given that there is no queue or points system yet, putting something in that’s optional for the hub can only be a benefit. Those who try it will report back as to how well it’s working.
How much do you trust the hub ? Well, isn’t that a moot point ? If you don’t trust it, don’t join it :)
I would say to start simply, more or less as I outlined above. Let the hub assign configurable values for points, (based on size of file for example), time per point, and the upload speed modifier. There’s no need for each client to report *what* file is being transferred to the hub, just how many bytes and at what speed. The hub is not involved in the transfers, just the accounting for them. It’s up to the clients to allow/disallow transfers based on the points in the downloader’s account.
As above, userA is the downloader, userB is the uploader. The only messages needed for the hub are :
1) userA -> hub : seq y received n bytes at x bytes/sec from userB.
2) userB -> hub : seq y sent n bytes at x bytes/sec to userA.
3) userB -> hub : request userA current points account.
Sequence numbers are to keep reports in sync. Points accounts are updated on receipt of paired msgs. Msg 3 lets userB determine whether to send next chunk of file – say per megabyte or so.
Older clients without the points code can still connect, and will accumulate time-based points. Since they can’t send updates to the hub, they won’t collect upload transfer points – their loss until they upgrade to a new client. They will still upload just fine, never sending updates to the hub, so there would be no controls/restrictions on them. Anyone can download as much as they want from an older client. The hub can of course refuse connection to older clients …
Then again, I’m not the coder here :) I can request all I want, but …
JC
Well, once the forum is up (at aforementioned unspecified date in the future), you’ll be free to resurrect one of the old posts on the subject or start a new one. It will be interesting to see what the current opinion is, as well as what others think about the specifics of your plan.
Until then, feel free to suggest blog topics here. :-)
Please change the values to standard, like a megabyte would be MB xD
Regards,
Vladimir
If you don’t like the binary units that arnetheduck introduced in 0.402, you’re free to override them with an appropriate language file. I can’t tell if you’re being serious or not, but it is a standard, although not “standard” in that it is what some users expect. This has come up before on the forum, and that’s my position.
I was wondering that could you write support for STUN to DC++?
STUN (RFC 3489) is a lightweight protocol that can be used to detect your NAT’s port mapping. This can then be used as the public IP address that DC++ utilizes.
This would ease those that have NAT’s in their network, so that they would no longer need to input their IP address manually to DC++. Not all of us can use UPnP you know..
mangusti, this isn’t for feature suggestions, but I’ll gladly muse with you.
In any case, STUN is targeted at allowing incoming UDP packets. The DC and ADC protocols use UDP sparingly and only for delivery of search results (and pings, which DC++ doesn’t support). A number of other P2P protocols have implemented a wrapper system to replicate TCP in UDP, but I’m not sure if that is related to STUN or not. Such support is largely out of the question for DC (clients communicate capabilities only when connected… with a TCP session), but perhaps would would be possible with ADC.
hey guys, new on this site but been using dc++ for years… mostly with sharing stuff on a removable drive, and before ive figured out how to change drive letters on windows , 2 things happened, the first was i had to reshare and rehash everytime windows decided to change the drive letter of my drive when i plugged it in, which is no problem since i leave dc running for days on end and the hashing gets done in a fraction of that time, but the second thing is completed downloads get stuck inside the incomplete directory if i forget to reassign dc++ to download into the correct drive letter, and all my downloaded stuff lose all their own directory structure…it happened a couple of times already… is there like, a ‘history of all downloaded files’ or something inside dc++ or something ? the files are all there , its mingled with the incomplete files and i can sort that out,but the directory structure is kinda important to me…
carmatic, what topic did you want us to write a blog entry about? It seems more like a request for support than anything.
That said, there is an option to log all (completed) downloads. Look in the settings under logs. I think it will show the final filename, with no directory structure. The log only knows the remote TTH and the local filename, so you can’t glean any directory structure from that. The failover for an inaccessible download directory isn’t the best, but I’m not sure if there’s a better way to do it (a “rename queue” between sessions is one solution, but if the download directory never becomes valid… recreating the directory structure in the incomplete directory could be a possibility, but I think there may be good reasons not to do that either.)
hi sorry about the request, im not used to this system , where you… ask people … to write a blog… about something??
thanks for the reply, anyway, i guess i’ll just have to live without knowing what directories the files are originally in…
maybe if the blog writer took one of the questions , and used it as the title for their newest entry, then the things raised in the question effectively becomes the topic
How about a blog topic for patches ? Well until Bugzilla is sorted again. Some patches might need input so they can be improved, or just comments / ideas, before being submitted.
e.g. a couple of line addition in SConstruct is needed to build the latest svn’s with Visual C++ Express and latest SDK installed. Now while these 2 line addition works fine for me, someone good with scons / python could improve it to check if these includes are needed, if the path exists, and maybe pull the correct path from the registry. And if that gets done, maybe worth submitting as a proper patch. :)
env.Append(CPPPATH = [‘C:/Program Files/Microsoft Platform SDK for Windows Server 2003 R2/Include/’])
env.Append(LIBPATH = [‘C:/Program Files/Microsoft Platform SDK for Windows Server 2003 R2/Lib/’])
If you need to talk about patches, use the Dev hub. If patches don’t need input, send them directly to arne.
one last question… is there an official forum with most number of people and where the developers hang out?
There’s no forum for DC++, as https://dcpp.wordpress.com/2007/01/16/forum-on-hiatus/ point out.
We have a hub designed for DC development related stuff, at adc://dcdev.no-ip.org:16591 Feel free to drop in. (An ADC compatible client is required.)
i have added that hub as a favourite, i think its cool if more people knew about that hub
hi i think some guides on dc++ on linux would be handy.
Using linuxDC++ and running a normal win client like apexdc++ on WINE and other setups.
especially aimed at the latest Ubuntu versions and Suse, Red Hat.
Thanks for the blog…
jim sherwood
Jim: I intend to create instruction videos for DC++ [on Windows XP] and LinuxDC++ [on Ubuntu 7.04]. However, the DC++ video will not come until DC++’s port to Smartwin is complete. I haven’t started, but the LinuxDC++ video will hopefully be compiled in a month or two, depending on how fond my laptop is of the screen capture software.
Having that said, there’s an excellent instruction guide on ubuntuforums.org, concerning installing LinuxDC++. Also, I haven’t tried using DC++ under Wine, but I can’t imagine it being difficult to setup? I’ll look into it, at least.
How about a post about the current state of the hublists?
Last time I checked a few days ago, the newest DC++ seems to be lobotomized by the lack of hubs…
There is already a link to the DC(++) FAQ, concerning hub lists. “Hub list” under the links category. I think it’s much better to keep up to date information in a FAQ entry than a blog entry.
If you refer to [1], then less than half of the lists actually work.
[1] http://www.dslreports.com/faq/8189
Yes, that’s the link I mean. It’s unfortunate that only half of them work. Send a mail to BSOD, since it’s he who manages the FAQ?
Sigh. Utf16: I accidentely deleted your message (I thought the message had been posted twice, as it looked like that in the control panel of this blog software). Sorry.
Anyway, “utf16” asked why DC++ doesn’t support unicode in chat, while file transfer work fine. (My phrasing, but it’s the jist of the message.)
On NMDC hubs, DC++ will use whatever encoding that the system is set to. Likewise, other users’ DC++ will use their system’s encoding. If two people are to chat on a NMDC hub, they both need to use an encoding in their system that are compatible. The protocol wasn’t written to support different encodings, which is why the client assume which encoding to use. (I think there is code in the development version that allow users to (partly, at least) select encoding, on a per-hub basis. (Like nick and description.))
However, on ADC hubs, this should not be a problem at all, as the protocol is designed to support unicode (UTF-8). Look out for ADC hubs, their address is prepended with “adc://”.
Ullner: Some nitpicking from me :)
If your local encoding is UTF-8 then NMDC actually support it. However, there is no specification that mandates a NMDC client to convert any local encoding to UTF-8 and vice versa (hell, there is no NMDC spec :-).
So, if DC++ were to always use Utf-8 for nicknames, description and chat in NMDC, that would be a completely straight forward thing to do.
A slight problem would be people running older versions that might get non-english characters garbled (so, upgrade!). Just they way they would if they joined a hub with users of mostly a different system encoding.
Another thing worth mentioning is that a local 8 bit encoding requires less bandwidth than Utf-8 for non-western languages. For instance, writing russian in KOI8-R or cp-1251 is typically half the size of the same text in Utf8. (With some asian languages the story is even worse).
Using Utf-8 all over the place for text handling would solve the garbled text problem, and allow users from different countries to join different hubs regardless of their system locale settings.
PeerAware use only Utf-8 for NMDC, so does QuickDC (if I ever will release that :-)
Hello once more,
I am really grateful that someone has replied to my desperate cry for help. Let me address some issues that you mentioned.
„On NMDC hubs, DC++ will use whatever encoding that the system is set to. However, on ADC hubs, this should not be a problem at all, as the protocol is designed to support unicode (UTF-8).“
There is something I cannot understand about protocols not being designed for UTF-8. If a piece of software can handle text encoded in one of the ancient ASCII encodings that use 8 bits to transfer information, it is then compatible with UTF-8. This encoding is actually a very quick workaround if the implementation of UTF-16 is not possible. As far as I understand, only two additional functions are necessary in your code:
1) the one that converts a given unicode codepoint to an ASCII character sequence (the japanese/chinese character “血” can be expressed in “è¡€” if your system locale is set to Western, but that really doesn’t matter);
2) the one that converts an ASCII character sequence back to a Unicode codepoint. If a client is unable to do that, as djoffset said, the text would be
garbled, but that is a lesser problem than having unrecoverable question marks instead.
This is how programs not supporting UTF-16 (like the ones that handle HTML, IRC, XML etc. protocols) work.
I’m sure I haven’t said anything you didn’t know before. So did I forget about something?
„So, if DC++ were to always use Utf-8 for nicknames, description and chat in NMDC, that would be a completely straight forward thing to do.“
Using UTF-8 for nicknames would not be possible as they can only be encoded in 7 bits (unless it’s hub dependant). UTF-7 can be used in this case, but I highly doubt you would mess around with that.
Oh, and I forgot…
„If your local encoding is UTF-8 then NMDC actually support it.“
Windows NT systems have nothing to do with UTF-8. You can’t set your local encoding to UTF-8 in Windows.
“If a piece of software can handle text encoded in one of the ancient ASCII encodings that use 8 bits to transfer information, it is then compatible with UTF-8.”
Isn’t this untrue? I thought that different code pages held different characters above 0x80, so two weren’t automatically equivalent. (ASCII defines the lower 128 only, right?) I know it is theoretically possible to determine character encoding from a stream when no other information is available (since web browsers are forced to do this quite often). However, I thought it was ugly and prone to mistakes. Isn’t this exactly the problem we’re avoiding by supporting Unicode only on ADC hubs?
„I thought that different code pages held different characters above 0×80, so two weren’t automatically equivalent.“
No, system doesn’t pay attention to the character that a certain code produces, it operates in numbers. The character “血” in UTF-8 will be encoded in the following ASCII sequence: 232, 161, 128. Different systems with different locales will produce different characters, but the code will remain the same.
„I know it is theoretically possible to determine character encoding from a stream when no other information is available (since web browsers are forced to do this quite often). However, I thought it was ugly and prone to mistakes.“
At the moment secure information interchange in DC networks can only take place in English. There is no need to determine charater encoding – the only way is to force UTF-8. Allowing users to choose ancient encodings will make the situation even worse.
You don’t seem to be responding to the set of issues I thought I was raising. Your original statement seemed to indicate that any encoding that produced 8-bits of output was automatically compatible with UTF-8. However, the characters over 0x80 vary from set to set, so you must know what character set they’re in to convert them properly to UTF-8, no? And if you don’t know the set, but instead guess at it, you’re bound not to get it right at least some of the time, and that code is complicated and specialized enough that nobody currently contributing to the project could write and maintain it.
„However, the characters over 0×80 vary from set to set, so you must know what character set they’re in to convert them properly to UTF-8, no?“
There is nothing to guess: the character set you type your text in is always UTF-16 (for Windows NT) or I missed something. You can already input any characters in chat window of DCpp, the program will display them correctly for you. People you are talking to will get them as question marks though.
If you want your implementation to be robust, you need to consider the type of input you’ll be receiving from the hub. With that in mind, do my concerns make more sense?
Sorry, I don’t understand. What different types of input are you referring to? Can you give an example?
Utf16:
“Using UTF-8 for nicknames would not be possible as they can only be encoded in 7 bits (unless it’s hub dependant). UTF-7 can be used in this case, but I highly doubt you would mess around with that.”
There is no specific 7bit requirement for NMDC. Utf-8 works fine, other non-DC++ clients do this.
“Windows NT systems have nothing to do with UTF-8. You can’t set your local encoding to UTF-8 in Windows.”
Perhaps not. But you can on Mac and Linux.
And btw. Browser detection of encoding is really naive and semi-automatic at best. It tries a few common types first, then falls back at your local encoding.
„There is no specific 7bit requirement for NMDC. Utf-8 works fine, other non-DC++ clients do this.“
Well, I’m glad to hear that, but somethow the hub I usually connect to does not allow nicknames with characters of codes higher than 0x80.
„Browser detection of encoding is really naive and semi-automatic at best.“
This is what happens when browser receives single byte data. If there were a popular browser compatible only with Unicode (this is what would be ideal for DC networks), those problems would vanish sooner or later.
“Well, I’m glad to hear that, but somethow the hub I usually connect to does not allow nicknames with characters of codes higher than 0×80.”
Yes, that is typically a hub specific limitation.
There are of course some security considerations that should be made when allowing full unicode in nick names (anagrams, anyone?).
I know I would appreciate if DC++ started using UTF-8 instead of default locale, as PeerAware would then be able to communicate with DC++ without strange characters displayed for anything above 0x80 in the chat window. But I think the main reason DC++ does not do this is a wish to move everyone onto ADC.
utf16: Each user’s chat, PM, or search could be sent to the hub in a different character set, and the hub will forward them (largely) unchanged. The client can be receiving text in a variety of encodings. If you’re going to use Unicode on NMDC hubs, I think correctly dealing with varying inputs makes for a better experience for the end user (and a transparent transition).
Todd, this is actually the situation we (well, at least me) want to avoid. Client should NOT be receiving text in a variety of encodings. The sole and only way of sending information over DC networks should be UTF-8. Why would you care about some old sleepyhead who is too lazy to update his software?
On the other hand, there is also a way to leave the default behaviour for the situations when a client still receives single byte data (for codes higher than 0x80). Currently the default (and only!) behaviour is the default character set display. It would be better than seing question marks all around. And it does not require some special or complicated code.
In conclusion, you can’t make it worse than it is now.
If you require everyone to upgrade their client software, what is the real difference between forcing UTF-8 on NMDC and ADC? For just a little extra effort, you have a protocol that was designed to do that from the beginning, with full specifications so clients know how they have to be programmed. Those extras with ADC are worth a lot, plus there’s built in expandability (no more of this $Lock and $Supports mechanism, plus the ability for clients to broadcast extensions, instead of connecting to them one by one.)
Sorry, now I’m completely confused. NMDC and ADC are not the only Direct Connect protocols, are they?
Oops, I was thinking about something else. I will propose to my administrator to move to ADC.
ADC isn’t the only proposal for a replacement protocol for the Direct Connect network, but it it is the only one I know of with multiple implementations. I know we’re in a bit of a catch-22 with ADC acceptance. An ADC hub with a YnHub-like GUI would be a great aid.
Hi!
“DC++ just encountered a fatal bug and should have written na exceptioninfo.txt the same directory as the executable. You can upload this file at http/dcplusplus.sf.net/crash/ to help us find out what happened (please do not report this bug tracker unless you know the exact steps to reproduce it…) Go there now? YES/NO”
This message always apear when i open DC++. What i must to do to repair or to solve a problem?
rockabilio, send me the crash log (probably c:\program files\dc++\exceptioninfo.txt) via email. Use the SF email address listed on this page: http://sourceforge.net/users/tepederzani/
If I know what causes it, I’ll give you a solution via email.
Developers of ADC protocol,
Please, add to a protocol possibility of receipt of list of files in a directory.
It is necessary that file list not begun to download (at the getting of a slot on a file list, client passes to me only content of necessary folder instead of file list).
I can’t parse everything you wrote, but I think you wanted what browse file list does; https://dcpp.wordpress.com/2006/03/09/browse-file-list/
That is, it’s already there, and has been for quite some time.
What I’d like to see is the ability to search on metadata. Things like MP3 ID3 tags and especially PDF author/title.
ucq1, I hadn’t heard the idea about PDF metadata before – interesting. When we get our bug/feature tracker back, I’ll add your suggestion to it, so it is not forgotten.
Oh, and another thing – not sure if this has been addressed, but there’s ways to address to problem of passive-to-passive transfer. One way is TCP simultaneous open. I’ll try to find out more about how well it is supported on various platforms. It is in the RFC.
ucq1, if you want to search using meta-data and file content I suggest using PeerAware. It is compatible with DC++ (NMDC) and indexes files by content, metadata and filename. Full disclosure: I am the author of PeerAware. http://www.peeraware.com/
The problem with using it is that when it returns results to DC++ clients those clients just might filter away the result due to the way DC++ handles multiple search requests.
ucq1: It’s STUNT, I believe. It’s something that could probably only be implemented in ADC, since clients can send arbitrary messages to each other through the hub, which would be important for negotiating the connection method.
jonnyrein: how are you tagging ADC search results with meta-data? Do you have specific implementation already? (For interoperability purposes.)
Todd: PeerAware does not use ADC, it is NMDC with a bunch of extensions:
passive to passive is supported using a proxy (the hub).
I plan to use a TCP overlay on top of STUN using nat traversal.
That would make the proxy solution a guaranteed fallback solution for the 5% of connections that can not be handled by STUN. (STUNT fails in about 11% of connection attempts)
I have looked at STUNT but that requires two network cards which is a hassle for hub operators. (Or I guess an active client could substitute for the second network card, but still a bit annoying. STUN is just simpler.)
A hub is built into PeerAware and runs as a service on windows.
It is controlled from the client (it is the same executable, just two different instances).
Search is sent out as $ESearch and results as $ESR to PeerAware hubs, and the hub handles fallbacks to normal NMDC clients. Protocol is not documented yet, but anyone can look at it with ethereal. Metadata is passed in the $ESR extension.
Hello all,
I am first time in here so it’s nice to meet you all, and I hope to have good useful time in this community.
Currently I am using latest classic version of DC++
I would like to know if there is some kind of implanted plug-In for it that will let me preview unfinished video files, which are in download process. May be there is a mod for DC++ that has this feature built in.
Thanks a lot.
DC++ doesn’t allow for plugins. However, you can go to http://www.dslreports.com/faq/6513 and see if you can find a mod that have previewing of files.
DC++ is now accessible to the blind and visually impaired using JAWS For Windows. I was hoping that this resource could be added in some way to your site as a resource for blind users of DC++, but I can’t find anywhere else to ask this question. I created these JAWS scripts to work with the JAWS For Windows screen reader, and the scripts enable all of the native DC++ functionality to work correctly, such as the keyboard accessibility, and the automatic announcement of chat and private messages as soon as they arrive. The GutterStar.net DC++ Scripts for JAWS can be found at:
http://gutterstar.net/dc_plus_plus_scripts.php
Thank you, and best wishes,
Bryan Garaventa
I’m a frequent lanparty-visitor and as you might know it’s the most used tool to share files. The tool is easy to use for new users and can be configured by expert users.
The one thing I’m missing for expert (or even for new) users, is being able to set a maximum number of connections to a harddisk. When 4 or more connections are made to one harddisk, the upload speed will drop from 10MB/sec (or higher) to 300KB/sec for each connection. This is a limitation in Windows, but can also make the system instable.
Are there any plans in the (near) future to make this a new feature? I know alot of sharers would like and love this feature :)
Not sure where to post a suggestion, so am gonna try my luck here.
It would be good to see the File –> Settings –> Connection Settings had an option to automatically populate the “External/WAN IP Address” via *http://www.whatismyip.com
i.e. User starts up DC++
DC++ notices that the “whatmyip” option is selcted and retrieves the webpage to find out the ip address.
DC++ finishes the startup sequence and the User is ready to go.
*They have a special page for developers to retrieve a users ip address:
http://www.whatismyip.com/automation/n09230945.asp
Thought I might send a tip about a little tool I’m developing. Maybe not worth a blog post but still something that might be useful for any user of DC++.
It will scan a local file-list and look for duplicate files in a few different ways (tth dupes, packed and unpacked versions of the same files, missing .rar-files etc). Its a great tool for people with large or unorganized shares to clean it up and save some valuable disk space. The latest version can be found here: http://www.crazybeavers.se/SiteData/Files/DupeCheck/Setup-1.02.exe
I am using DC++ 0.699 in Ubuntu 8.04…..Most of the stuff i cant download with the error : ” Remote Client does not fully support TTH- cannot download”
Plz Help….
Any questions you have please post on http://launchpad.net/dcplusplus
Suggestion:
Currently I’ve limeted my amount of upload slots to 1, because I have a very limited upload speed. :P So I want at least someone to be able to download something, then hopefully alternative sources can help me uploading the rest.. But there is a problem.
The DC++ team has decided, that minislots have the least size of 3 and you cannot eliminate the possibility of people ripping you from files lower then 64 kb.. :p Now, my actual upload speed has limited to 1/4, due to 1 upload slot outconquered by 3 minislots. I have 40 ppl in my upload que and still a lot of people downloading my filelist + when people start ripping small files such as text documents and pictures, I get a lot of spikes because when the files start uploading it always uses 100% of my upload speed (and at no point accepts the upload limit), so I cannot use my internet for something realtime dependent such as gaming without getting a lot of latency.
Now it wouldn’t matter if I setted my amount of upload slots up to 6, because then I would still miss a third of my upload speed and then nobody would ever finish off any larger files. I could ofc fix the annoying fact about the minislots taking all of my upload speed by setting the minislot size to 16GB, but then again I would have too many slots open for my upload speed.
My suggestion is: Could you set minislot-amount to zero if uploadque is larger than 6-10 people or if uploadspeed(limited else selected or based on actual) * amount of data in data que > 43200 seconds (12 hours)
That would be freaking awesome.
tzepesch: Post any questions pertaining directly of DC++ at DC++’s Launchpad.
Hi !
i think this is the best p2p format ever , but needs some improvements to make it more user friendly and most important it needs host functions included in the client.
This means , anyone can not just join hubs and share but also make hubs.
think about it !
just like in IRC clients you can create and register a channel with few commands.
if we could do that in dc++ clients im sure this format would snow ball to beat torrents in popularity.
another topic
why dc++ doesn’t work like rev connect ?
meaning , same file can be downloaded from more then a single source ?
once again , if this would be implemented in a flawless way … again another reason to beat torrents hands down.
just my 2 cents
keep up the good work !
I’m trying to do a DC++ client in Python, just for fun.
The biggest problem for me is find useful and clear documentation about ADC/NMDC… Please, dont get me wrong but, the ADC’s doc on SourceForge is very confuse for me. It looks like an unfinnished documentation.
I would like to see a post directed to those ones who want to do their DC++ clients. A post with links to docs of protocols.
Thanks you
Helder: 1. The documentation for NMDC is at nmdc.sf.net 2. It seems you found the documentation for ADC, at adc.sf.net. 3. What in the documentation makes you confusing? What’s the “unfinished” part? 4. Go to dcbase.org/forums and ask your question if you have a specific one. 5. There is also the development talk hub at adcs://hub.dcbase.org:16591 (6. “DC client”, not “DC++ client”. The network is called the former while the latter is a particular client.)
Hi Fredrik. Thank you for fast reply. Those information helped me a lot.
When I said “like unfinished”, Actually I didn’t want to say “unfinished”. I mean that ADC doc is a little bit confuse, for example section 5.3.3. It says “SID sid”. SID is the command? And what is “sid”? I know “sid” are base32-encoded strings, but would be interesting have some example of how would the the whole message.
This was just an example. I’ll read the NMDC doc.
Thank you Fredrik. You guys do a good job.
“SID sid”; SID is the name of the command (also the title of that section) and sid is a positional parameter and references the Session ID in 3.5.1.
Each command lists the name of the command and the positional parameters that follow. Any named parameters (those that start with two upper-case letters) is in a table below. I can see that it may be slightly confusing, but it’s this way to not be so verbose. E.g., the message type is also omitted because it’s not of the command’s concern. Most of the time, the parameters are explained in the text that follow. Also, note the syntax (3.2), as it describes what you can and can’t use in characters etc.
If you can, it’d be good if you created a list of items that you do not understand or find confusing and we can see if it’s possible to make it more clear in the specification.
Have a look at the SVN for the file trunk/ADC.txt as it also contains some minor changes (you need ASCIIDoc if you want to generate an HTML doc).
Please join us in the development hub, there’s almost always someone there that can answer your questions.
Ok, thanks for the explanation, Fredrik.
When I have more questions I’ll ask at dev hub.
Are you guys going to do anything about the recent Sourceforge hijackings? You may want to consider moving your project elsewhere.
Christopher: We are discussing what we are going to do regarding SourceForge, I will write up a blog post what our options are and what we have discussed.
Here it is: https://dcpp.wordpress.com/2015/08/16/addressing-dcs-service-provider-sourceforge/
Is there any good tutorial on developing plugins for dc++