Crise
Management-
Content count
3008 -
Joined
-
Last visited
Posts posted by Crise
-
-
You have your answer then, the hub is not a generally available public hub, ergo you are not supposed to be able to connect to it... and as for getting around that my initial reply covered that already.
If you are dead set on finding out how to access this hub, the only people who can answer you are the people running it. Chances are though, if you don't already know how then it is not something you can even do.
This is clearly a hub set up by an ISP in some country (I don't know which, nor do I want to), so they have a vested interest in keeping people not part of their network out of it.
-
Hi,
You can generally not go shopping for a specific IP address... one from a specific country or state yes, but that is generally about the granularity you can have using VPN services. If an ISP happens to also sell VPN services then that way it might be possible to get an external IP in their ranges, however, otherwise not really.
Usually hubs with IP address restrictions have those restrictions for a reason, for instance because traffic outside of their ISP's own network costs the users money by volume. So a chances of you finding a way to get your IP address in their allowed range is literally close to zero.
If anything you should try and find out why the hub has this limitation, that should tell you also how to get access to an IP in their allowed list (although, as I said, I'd wager it is not something you can just do very easily).
-
Looking into it some more, it is likely there is an issue with the way openssl is being compiled with 1.6.1 and newer, I will see to it that this is addressed for XP builds with the next version, however, I can't promise it will remedy the issue as I have no access to test on windows XP.
-
My first instinct, as a workaround, would be to disable the bandwidth limiter if you are using that... as for the crash itself I will have to look into it more.
-
Can you tell me which hub software that is... it should be simple to fix, but I have never encountered that before.
-
It isn't really a question of how hard it is, XP support for any application these days is pretty much on life support, it has already required separate binaries to be compiled since forever and it is only a matter of time until that is no longer possible.
I'd give you an year tops, maybe two if you are lucky, but Microsoft isn't going to retain XP compatability in MSVC forever, it is just a matter of time until the XP toolchain is either removed or becomes so diverged from the primary compiler that XP support is no longer feasible.
The reason why we opted for this approach for now is mainly because the installer kept inflating in size with every release, so for 1.6.2 I did everything I could to cut it down. Ideally we would have a stub installer that would download the right components for your machine that wouldn't even need to be repackaged for different versions necessarily unfortunately, Inno Setup has no feasible support for such installers. Not that it can't be done, but it is basically a duct tape solution and lacking of the necessary security features.
-
With this version the way releases are packaged has also changed, we have started offering two separate installers for 32-bit and 64-bit operating systems respectively. The download page will offer one to you based on whether you are using a 32-bit or 64-bit browser. Additionally, XP compatible binaries have been removed from the installers.
In the event that you still need to run ApexDC on XP, or if you are using a very old processor these binaries are now offered, for a time, as a separate slim binary only package over on SourceForge. The future of XP compatible binaries going forward will be determined by metrics on this distribution, as well as eventually by the end of XP support from MSVC.
-
Right, I vaguely remember a protocol called NMDC being superseded by ADC years ago... while this may seem unprofessional, to tell the truth my DC usage is such that this issue isn't something I would even be on my radar after a two year hiatus (I have neither shared nor searched anything in DC, definitely not in NMDC hubs for way more than two years).
Besides the primary responsibility to fix this issue is on hub developers and admins to make sure their hubs are not vulnerable as I understand it.
Edit: great minds think alike ;).
-
It is on a list... that is all I can say, however, I don't have a setup to properly test IPv6 connectivity at the moment
-
Well that's a first I admit, would be interesting to see a filelist that gets it to do that... if you do come across it, please PM me a copy.
-
21 hours ago, Mek said:Yes, I have the same problem. Probably it's a bug in ApexDC.
If the client doesn't crash or lock up, then it is just the user being impatient (and for those we have a handy command called "Browse Filelist", you can even make it the default action).
On a more serious note, the reason why large filelists can take a long time to open is because recursion is slow... this is true for C and C++ in particular because for each recursive call a new stack frame has to be built. Recursion has its merits but it almost never is fast (in these kind of languages, compiler optimizations aside) when it gets complicated enough, certain types of recursion can even be prohibitively wasteful (such as running identical calculation is multiple branches of the recursion tree, see fibonacci numbers.)
The reality of the situation is that any DC++ based DC client is old, to the point where what was considered a big filelist back then didn't create a big noticeable slowdown on client side, whereas what is considered big filelist now is an order of magnitude larger than what the filelist browser was originally built to handle. I also have to note that you can have a filelist in the magnitude of several TB's of shared data that opens just fine, this is the case when you exclusively share very large files, however, if you share that kind data amounts comprised of several thousands of small files then yeah it is going to be slow (especially if you have meticulously organized the files in a folder tree that keeps on growing in depth).
Edit: above is written with the assumption that the list is well formed... and to know otherwise I'd have to see the actual list that manifests these issues (preferrably shrunk to be as small of a list as possible).
-
The way I see this should be done is basically start with an empty csv file and only add the rules you want to it. Trying to tweak the existing database will have a high risk of having some other/later rule overwrite your changes,
-
Last time we tried to host the update check files on our own server we ended up unintentionally ddos'ing ourselves that outdated version file exists because of a bunch of very old versions that reference it.
SourceForge should be fully operational some time in the coming week... according to http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration/
-
Re: DHT bootstrapping, even with those errors, my DHT pool seems to have been populated right after starting the client (currently at some 1750+ nodes). I assume these partially came from the previous session. So would it still be necessary for Apex to try and bootstrap that if it's already populated?
DHT retains records of nodes from previous session yes, the web bootstrap is only vital when on a fresh install or when all the nodes from previous session are invalid (say ou don't run apexdc for a week for example and that becomes a likely scenario).
I agree that the boostrap could be delayed and then skipped if you already have valid nodes from previous session.
-
When it comes to DHT bootstrap... that is hosted on StrongDC's SourceForge web space... so we have no real control over it, short of hosting our own copy (which we'd first have to develop since the code for the web bootstrap isn't readily available).
Re update check, thanks for spotting that typo... I'll make sure it is fixed as soon as possible. However, SourceForge recently had a catastrophic hardware fault, and basically all services are down since early yesterday evening. We don't know when these services will be restored, but DHT bootstrap should resolve when that happens (hopefully).
-
I apologize for any inconvenience this issue may have caused, it should be resolved for all versions now.
-
-
You probably need a new build, the server side implementation that results in this error has changed because of the forums being upgraded but I will check if there is something to be done on the server side first. My own builds work, so it is quite curious case.
-
Which TLSv1.2 ciphers are allowed in ApexDC?
Edit: removed the listing for future, to avoid outdated information being left here, one can always find the up to date list of ciphers from the source code distribution.
-
OpenSSL has absolutely horrible default ciphers, so in that regards AirDC++'s solution is not ideal either (hello null ciphers etc.) OpenSSL has a terrible track record with its default configuration options overall.
Also for the record, ApexDC already has TLS 1.2. Just to add AES-256 can in fact be slightly less secure than AES-128, so there is that also.
-
This has nothing to do with the files being small, these are actually identical to other files... it has to do with DVD file formats. There should be an option somewhere to download duplicate files that will solve this issue.
-
No answers !!
Thank you for your help ...To be honest, there probably aren't any answers because even I couldn't tell you off the top of my head if such option exists. Although, it probably doesn't (as in if it did I did not create it or recall seeing anything related to it during the entire lifespan of ApexDC).
As to why that is the case it would be because saving each windows exact metrics and position and restoring it correctly would actually be pretty complicated. The best alternative is to allow you to start up ApexDC with either tiled or cascaded windows. However, a complete saving and restoring of window positions would have number of edge and corner cases that likely would cause it to break unless handled with care.
-
Do you use any plugins?
-
Most likely there is not a whole lot you can do, free wifi hotspots can have strict limitations or total block on used ports or protocols.
ApexDC++ 1.6.3 maintenance update available
in News
Posted
It has been quite a while again.
We are pleased to announce the immediate availability of 1.6.3 a maintenance update continuing in the same vein as the two before it. This time the focus is on updating third party dependencies and build tools with the latest security updates and patches. Notably the binaries distributed for the Windows XP operating system had a configuration issue for the previous version and this has now been addressed for our friends still in the past.
A full list of changes are available on here. As usual we strongly recommend upgrading to 1.6.3 as soon as possible, regardless of which version of Windows you happen to be running. For the people who need the XP compatible binaries, we would like to give this remainder about changes introduced in release packaging with the previous version.
Download: ApexDC++ 1.6.3
Update: 1.6.3 has an issue with compressed transfers, that affects connectivity, turning off the setting "Enable safe and compressed transfers" should avoid this issue on 1.6.3. Alternatively you can hold off upgrading until a fix is available.