burek

Hi again, Yeah I know, most of you are wondering right now am I such a n00b or a crazy one, for mentioning something that "just can't be done" For those of you who have a patience to read this message, I think it will be worth of your time spent reading it. Let's begin. Apache web server hosts multiple domains (hostnames or just hosts) on a single ip address with the same port (80) for all domains. Now, in DC world, we have a problem. When a hub owner wants to get his hub hosted on some server, a hub hoster (server owner) asks the hub owner what is the port of his hub, so he can see if that port is available on his server, to host that hub. If the port is already occupied by some other hub, too bad. Now, I think I've found solution for this. Let's first see how apache server does this. Let's suppose we have a domain named 'www.example.com' and the ip of the hosting server is '1.2.3.4', and web port is 80. When we open up the browser and type in the address 'www.example.com', our browser quickly finds (using dns) that the ip address assigned to that domain is '1.2.3.4' and opens a tcp connection to 1.2.3.4:80. After the browser connects to the web server, it sends a HTTP request, that also contains something like this (in the header): Host: www.example.com That line helps web server to understand what website (of all those websites hosted on that server) should be fetched and displayed to our browser. Now, many of you believe this is impossible with dc, simply because of the fact that, once the tcp connection is established with the server, the only way to "switch" the connection to the correct hub is to redirect a user (using NMDC command) to the correct hub. But let's see a different approach on this. I'll suppose you are familiar with NAT and port forwarding. Shortly, on all major Operating Systems, programs exist that can reroute an incoming connection request (aimed at some port) to another ip:port or just to another port. For example, you could forward your local port 120 to your web server port 80 and that way all tcp connections to your ip at port 120 would also be replied by your web server, even though it is not directly listening on port 120. The idea is (maybe not so) simple. Let's assume hub hosting machine hosts several hubs at ports 1234, 1235, 1236.. Also, let's assume that port 411 (the default dc server's port) has got port forwarding rules, that redirect traffic from the internet, aimed at the port 411 to the correct local port (1234, 1235, ...). Then, DC++ clients would all connect to the default port 411, for all localy hosted hubs, not even knowing that those hubs are running on different ports (1234, 1235, ...). Simple, right? Now, before you start yelling at me asking "how can NAT know which incoming connection to forward to which local port/hub?", let me say for now, there is, relatively easy way to determine this. And it's a low level solution (on IP level), which doesn't require messing around with higher level protocols, like NMDC. So, how does it know how to redirect connections correctly? First, take a look at http://en.wikipedia.org/wiki/IPv4#Packet_structure There you can see an IP packet structure layot. Take a look at the offset 160 (IP Options). If you know what this is, you also know that you can implement your own (custom) option, that you need. Now, let's finish the idea. If we could make DC++ clients send just the first TCP SYN packet (in a 3-way handshake) configured with a new, custom, TCP Option, "hubname" (for example), then we can practically send the hub name we want to connect to, even before the TCP connection has been established. So, our port forwarding utility, can now understand where does it need to port forward this connection (at which local port), using a list of rules that will say what hub is located at what local port. Now, isn't that cool? )) Shortly, DC++ clients could send an extra TCP Option, in the first TCP SYN packet only, that contains a hub_hostname (dns hostname), to inform the iptables (or some other NAT tool) how to correctly forward the incoming tcp connection to a local port, where that hub is located. An important thing here is, we didn't break any standards/protocols with this. Older hub hostings, that don't implement such a NAT tool, will still work without problems, not even knowing that some change has occured. And older dc clients that connect to newer hubs, will simply get connected to a default hub, that's on port 411 (because it will not send TCP OPTION in SYN packet and will not get redirected anywhere). Sorry for the amount of the text written here, but I think it's a very interesting thing, especially because the implementation of this feature takes just the adding of the hub's address into an extra tcp option field, and on the server side, a proper port forwarding tool with custom rules, that's all. And what we get with this? A single server that hosts many hubs, all of them using the same (default) port 411. Well, isn't that what was needed for so long, so far..? b.

Hi, It might be wise to use only 1 MDI Child Window for private chats, instead of opening one for each private conversation. Same goes for public hubs, search, file lists, etc. Explanation: Instead of using each mdi child window for each item (hub, pm, search, etc.) it would be more efficient to keep the info, related to that item, in the memory structure and when the user switches to another item, just to update the content of the mdi child window with the info from the memory structure for that item. This way Apex would allocate a lot less GDI objects, handles and total memory. I'm telling this from my own personal experience, while programming MDI applications, so you might actually considering discussion about this topic with root developers (DC++) too, since it would be more effective for all derivative client apps. Cheers.

Is there an option to disable random segment selection? This is very annoying when I want to have enough content downloaded from the beginning of the file, so that I can use Preview option, but random selection makes that nearly impossible..

well, the reason i've posted it here is because i prefer apexdc++ client because of the range of its features, in contrast to other dc++ derivatives.. but the toast replied the way he replied, not helping at all nor showing any interest, which actually pissed me off.. also this topic doesn't have anything to do with nmdc/adc protocol at all.. it is a very low approach (on IP level) and that's the 2nd thing that annoyed me.. anyway, no offence, but toast .. if users of your dc client care enough to come here and offer you a nice new feature, which should help all of us, especially your dc client, the least you could do is to show some interest in it or politely deny that feature, explaining why it is not the good choice.. you could also just post the topic in the right place and give me the link to further follow the conversation.. after all i'm giving you a suggestion and its up to you if you need it or not.. and judging by your reaction i figured you're not interested at all in such a feature, which i really couldn't understand, since so many hub hosters are eager to have something like this.. lee, thanks for your comment, i'll calm down and post this on adcportal.. after all, we all need this, not just me.. P.S. I need to add one more thing.. I went to adc portal, just to register, and copy this topic, but what I've encountered "Confirmation of registration Which of these are ADC compatible DC clients Please drag the options with the mouse to the correct list, to avoid automated registrations." I'll just say lol at this and stop trying to please all your wishes.. I gave you the idea, if you need it, go ahead, implement that single setsockopt() and make us all happy. If you don't want, I really don't care. Also, toast, i'll reply to you here instead of bugtrack: "Well if you took the time to actually read more of the post you would see that not all developers are here and if you really wanna reach out to em instead of trying to pick a fight with me you could clearly see that we are working on something simular at adcportal called failover but if you dont wanna reg and talk to the devs im totally fine with that.." I had good intentions, but I don't have time to play games, just to be able to "really reach out to" you, developers, as some kind of ultimate gods or such sh.t, i don't need that in my life, i've got better things to do. Cheers.

? well, ok.. my bad, I shouldn't have suggest this idea to you anyway.. so many times I've seen negative replies here, I'm really starting to doubt if you are even interested in making progress or you are scared to break things that work so far or you just don't know how to implement something.. I dunno and personally I don't care anymore.. I've being recommended apexdc++ for so long, but I think I'm not gonna do it anymore.. There are a lot of other dc++ developers, making effort to actually improve some things in dc world in contrast of apex.. Anyway, you can delete that post of mine. cheers

That thingie for bitrate (and in general, some information about a multimedia file) would be highly appreciated, if implemented. I've had a lot of trouble finding the clean and hi-quality music myself and I bet the others have been thinking of this cool option too. I know you guys don't want to extend NMDC anymore, but it would be worth extending the $SR message, with additional multimedia field in it (adding a new option in $Supports command, something like "$Supports MMInfoInSearch" (MM stands for multimedia) or something. I'm not sure if that's complicated to implement, but I know it would be very cool.

Hi, Could you please add these extensions as default ignored file extensions (so that users don't share these kind of files, by default): *.!ut;*.bc!;*.dctmp;*.jc!;*.ANTIFRAG;*.fb!;*.!bt;*.ob!;*.nc?; Explanation of extensions: !ut - µTorrent Incomplete Download bc! - BitComet Incomplete Download dctmp - DC++ Incomplete Download File jc! - FlashGet Intermediate Download ANTIFRAG - DC++ incomplete download fb! - FlashGet Incomplete Download !bt - BitTorrent Partially Downloaded File ob! - Orbit Downloader Incomplete Download nc? - FlashGet download manager incomplete file Cheers :)

Cool, nice Also, just a thought.. A lot of viruses tend to mask themselves by taking the names of regular files, appending the extension .exe at the end of the regular file's name, for example: Dire Straits-Sultans Of Swing-DVD Rip-DivX5-By Proximus.avi.exe So, my suggestion is also to add these extensions too: .jpg.exe, .avi.exe, .mp3.exe, .doc.exe and similar. Thanks.

Hi, Thanks for your reply. I'm in a hurry, but let me just answer to this shortcut question. Many people have set their shortcuts to "Run as admin" on windows 7 and when the shortcut is overwritten, this no longer applies, so they can't download anything again, and thus they revert to 1.3.6, blaming us for "instable versions", etc. I'm not sure is this the exact scenario why downloads don't work for them, but I guessed it could be that, because those that were complaining were all using win7/vista.

Hi, I have some critics regarding v1.3.8. so I'll just cut to the case. First of all, in the installer process, there was no option to choose a Start Menu group (where to put the shortcut for the ApexDC++), so the installer has effectively overwritten my old ApexDC++ shortcut. Second, please remove adware/advertisements from the installer, because it makes our users nervous, complaining about doubts that this software is becoming a spyware/spamware or something like that. My personal opinion is that your project should be sponsored by some kind of advertisement, to support the whole idea, but this is not the right way (to put it directly into installer). If this advertisement continues to make our users nervous, I'll just have to drop the support for ApexDC++ and switch to StrongDC++ or some other client (recommending it to our users), because I honestly don't have time to explain to all of them these things. And the third complaint, in the public hublists, there is a link to http://www.hublista.hu/hublist.xml.bz2... But.. Take a look here: http://www.hublista.hu/banned (the list of banned hubs) and see the reasons for banning hubs ("Nem magyar hub.", "Hungarian language is not allowed on main chat.")... Meaning, that list is ment for magyar hubs only. Obviously, there is no need to include that kind of hublist into ApexDC++ I don't want you to think I'm just complaining, because ApexDC++ is a great piece of software, but these things are really something that should be considered if you still intend to be the No1 DC client. Edit: Also, could you please standardize the download links (slim downloads especially), so there will be no situation where links for one version of apexdc++ display as "blah_32bit.7z" and in the next version display "blah_x86.7z". It is really painful to always do printscreens because of that, to be able to always have the latest fresh tutorial on how to update ApexDC++.. Thanks.

Hi, This is more like a suggestion to improve accessibility, rather than to implement something very necessairy/functional Anyway, when there are a lot of smileys in smiley packs, when users click the smiley, to see all of the emoticons in that pack, the box appears, showing smileys. That box is squared, but most of the computer monitors are not squared, but like more wider than taller So, when there are a lot of smileys, that box goes out of screen. I would like that box more to expand horizontally more than vertically (following the monitor's geometry). Or if it's possible, to add scrollbars to that box, so it can be scrolled nicely. Cheers :)

Great news ) I'm really excited to see and test the linux version of this famous client :)

Hi, I've tried a lot of combinations for up/down limits and I know there has to be a ratio of aprox. 1/7 for up/down values, but no matter what I put into the upload box, it restores the 54 KB/s when I reopen that config window. burek.

Well, I know that from long time ago, since I'm not a noob.. Did you try to regenerate that bug? P.S. How can you get 54KB/s from 5*(...) :thumbsup:

Edit: Sorry but we don't allow this.

We are using emoticon pack made for apex, which was successfully used on all versions from v1.1 up until v1.3, which now doesn't show emoticons for that particular emoticon pack. Can you please examine what could be the problem? Here is the emoticon pack in question: http://www.gusari.org/uploads/Gusari2009.zip

Thanks a lot, that was the issue here However, the last emoticon ":gusari:" is not displayed at all. It was a bit bigger image than other emoticons (152 x 125 pixels), which was also displayed correctly in previous versions of apex, but is not displayed correctly now (see the screenshot). Was there any other change, regarding emoticons, other than new XML parser, that could've afftect this? Thanks again for your help :)

I just did what you said, but with no luck. Emoticons are still not displayed. Just to mention, at least 30+ users reported this so far, so I believe this is not just a simple issue, but some broken functionality. Can some of developers try that emopack and see what causes the trouble (maybe some smilies are "incompatible" or something), so I can temporarily resolve the issue until some bugfix is released? Thanks in advance.

Hi, I really need some advice on this topic, so if anyone has any suggestions how to resolve the issue, thanks a lot in advance! The problem is in the way DC clients handle CTM message. For example, take a look at the diagram to better understand the problem. 2 dc clients are connected to the same hub and client Alice (active connection setup) wants to download something from client Bob. So the communication goes like this: 1) Alice > hub $ConnectToMe Bob 1.2.3.4:56 2) hub > Bob $ConnectToMe Bob 1.2.3.4:56 3) Bob > Alice (through p2p link) $MyNick Bob|$Lock ... 4) Alice > Bob (through p2p link) $MyNick Alice|$Lock ... This is all great if Alice and Bob are on the same hub. But.. If you link hubs (with any kind of hublink soft) Alice and Bob would have prefixes of their respective hubs and their conversation would most probably look like this: 1) Alice > hub1 $ConnectToMe Hub2:Bob 1.2.3.4:56 1a) hub1 forwards msg to hub2 2) hub2 > Bob $ConnectToMe Hub2:Bob 1.2.3.4:56 3) Bob > Alice (through p2p link) $MyNick Bob|$Lock ... now the following step will not gonna happen.. 4) Alice > Bob (through p2p link) $MyNick Alice|$Lock ... Why? Because dc client Alice will check its own hub (Hub1) to see if the nick Bob is on that hub (which is not true), and if not, it will ignore the message. This is the "default" behavior regarding the implementation of NMDC protocol. How can this be resolved? What can be done so that CTM works across hubs? If you have ANY ideas, I'm eager to hear them, really and also, thanks in advance for any kind of help. I really appreciate it! burek. P.S. Another approach of hublinking would be to require all nicks to be unique across the entire network, so we wouldn't even have this problem. Thanks in advance again to whoever helps to resolve this issue.

:whistling: it seems like im on my own now.. however, would you mind if i create a new project on sourceforge, based on apexdc++, with this extended feature implemented?

Hi again, I've tried to ask DC++ developers to make a simple improvement over the usual CTM msg handling, but they don't seem willing to do so, and, frankly, I don't know why, especially because that change is backward compatible with any older dc client and plus, it improves security a little bit. But it's their project and I can't blame them whatever they decide: https://bugs.launchpad.net/dcplusplus/+bug/461785 Anyway, I must now ask the same question here, if your developers are willing to make that change... P.S. This is needed only for NMDC protocol, not ADC. Here is the copy of the proposed solution (a little bit changed, to reflect the real situation):

there CANT be no confusion, having 2 nicks from the same ip in the hub.. because it is the same thing when you connect one nick via hostname and another via ip.. so, there cant be no confusion for sure.. all $search/$ctm msgs are dispatched properly, so I really dont see what "race condition" would be problematic here..? as far as im concerned.. i asked for this feature because i thought it could be useful, not because only I want to have it.. I already recompiled Apex with a lot more changes than I posted here, and customized it heavily, so I'm pretty satisfied with it.. but I'm asking this because it would be a useful feature for ops that cant have share enabled (because of the copyright infringement), so it would be notorious that they need to start 2 instances of 1 application only to be able to connect with another nick.. anyway, no matter what, it still think this would be a useful feature for everyone..

Hi, Could you please make it so I can add more nicks for one hub in favorite hubs list, because, if I'm operator/admin on some hubs and I can't have share, I need another account (regular registered user) which has share enabled. In the current version of ApexDC++ that is not the case, since the program does not allow creation of more items in favorite hubs list that have the same hub address field. Thanks in advance.

and if hub(s) ip(s) changes frequently, you've got yourself a regular job of constantly nothing but updating ips in fav hubs no really, can this feature be implemented, please? :)

Hi, Can you please add our flag (Serbian) in the public hublist for Serbian hubs? You can find our flag here: http://en.wikipedia.org/wiki/Serbia Thanks in advance.