burek

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

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.

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.

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, 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 :)

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 :)

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:

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.

Edit: Sorry but we don't allow this.