-
Content count
80 -
Joined
-
Last visited
Posts posted by poy
-
-
This is a problem with XP i believe, heard that in vista it works as expectedyou can solve this by using Trem's method in his fulDC mod: store the positions of links in a vector, and check in respond to the WM_MOUSEMOVE message if the mouse is over one of these links; then show a hand cursor in such a case. this way, you can apply any formatting you wish to the links; they won't have the default Windows theme color
Personally i like that feature, but that's also the reason it was removed from dcdm svn last year.i'd leave it in the About box, though; it's always easier to see the mem usage there than to do a Ctrl+Alt+Del. i don't think only one call would cause a crash... :)
-
I would like to see Follow last redirect disabled by defult.and i prefer it on by default... this would need some voting or something, but i think most people keep it enabled.
-
1. Direct connection via specified port number.2. Direct connection via standard port number (1412)
3. UPnP
4. Outgoing AND Incoming connection via SOCKS 5 proxy (works for any firewall, proxy can be reached via 80 port) and client can establish listening TCP/UDP port on proxy server, packets then forwarded from proxy to client.
5. If everything fails - then a warning must be displayed to the user, and client goes into passive mode.
there is one thing you have forgotten, and that is to my mind the most important: telling the user to stay in active mode, and giving him instructions on how to forward ports manually. because, in many cases, when both direct connection and UPnP fail, i think a Socks5 proxy isn't really a good solution, and it would be better to have the user manually forward the right ports.
-
i might be dumb, but i don't understand the request... i mean, on Windows systems, you already have a button to minimize the window, so why do you want another one to do what the former already does? :D
-
Hmm... Apex is really good DC client......also Apex have big range of internal and external commands...
...some commands can be executed by pressing hot key...
...something not...
...something we need type in chat manually...
...but we can't type command in chat by pressing some hotkey and we can't use alternative hotkeys for already existing commands...
...also we can't control DC outside they window...
What about creating hotkey manager? Something like in foobar2000. But add ability to create manual commands... for example for chat commands... I'm wrote about using Ctrl+F to add text "/f" command in chat... What about special syntax? Like "/f %s" - replace chat string "%s" with "/f" + "%s" if user press hotkey...
And so on...
there could be one easy thing of this kind: bind texts to Ctrl + 0, 1, ..., 9 (from the keypad) so that when you press one of these combinations, it either adds the binded text to the message edit box or sends it. this way, people could bind /f, or some ascii pictures, etc...
-
But this looks for me like a workaround, not a real solution.from my point of view, it's your solution (which is based on chat messages) that seems more like a workaround...
P. S. What you meant by "open to abuse"?dunno what he meant, maybe flooding. just activate such a thing in DC++ (show joins/parts) and you will see the **** it produces when someone has connection problems, and parts/joins every minute...
-
i've not tried it, but i believe you could try Ctrl + F or F3 in the hub view ;)
-
it's a very good idea; i would choose the $Supports method.
-
Yes, but since the person doing the checking is usually the hub OP/Owner, this shouldn't be a problem... It's up to him to set the message on hubside and his client. For several hubs there may be several messages, divided by some separator?for several hubs, there can be some kind of manager like the one that manages the user commands, etc.
anyway, this sounds really weird to me and i believe such stuff should be done hub-side, but shouldn't be integrated in a client.
-
But when the client receives a message like "The VIP X has entered" (probably it will need a flexible definition for it in settings), can't it remember the status for the respective VIP?yes, in such a case you can. but all hubs don't send such messages... it would be hub-specific.
-
Take a look into mBot of MirandaIM. It's small, uses standart php library and you can script on it almost everything. And, of course, its the plugin.i don't get it, why do you want to use PHP? LUA can do fine for a webserver, or working on files, etc. ok, not as great as PHP...
-
Ok here goes, a new emule version just came up, and there is a realy nice feature called Protocol Obfuscation. it is explained very vell right HERE.in Short:
And i was just thinking if somewhere in the near future it could be inplemented into the ApexDC too if it is at all possible. Best of all since the emule project is opensource the idea and the code could also be borrowed
i've not looked at the details of the protocol eMule uses, but there is already a way to establish SSL connections on an ADC hub. wait and see... :D
-
It was removed by BM from SDC++ in the name of less resource consumption. Personally I would like it back, along with 2 other things removed, but maybe not only removed but with some improvements...system log like in DC++ shows to much spam, maybe along with some filter it would be nice (to show only important events, like errors).
i use 2 ways to see the system log:
- i move my mouse over the status bar, and it gives me the last system log entries;
- if i want further details, i simply open the system log file.
so i don't think this system log view would be useful to me...
-
maybe it is not in spirit of p2p?of course, some people would answer no to this question, but actually, i know of a hub where i was which did allow searchers of this kind to connect, because of a simple reason: if the searcher finds the file he's looking for on your hub, he'll come on your hub to download, and he might like it and stay on it since it's the hub that had the file he's been searching for so long...
i don't get it why noone implented this before (or i didn't hear about it).i've heard of 2 tools that can to this: MoGLO (tried it) and DCGUI.
MoGLO gave me very good results, but this was some years ago, and i think MoGLO is usually banned now. however, if you find a hub like the one i've described before, it will still work.
never tried DCGUI, and i'm not sure this one's integrated multi-hub search can be banned.
-
That's for NAT problems, not closed ports. DC++ handles network addres translation fine. It you read the Technical specification, you still need to open a UDP port for that to work.ok, ok, i hadn't read (*and understood*) all the details... :blushing:
actually, i got the link from here: http://dcpp.net/bugzilla/show_bug.cgi?id=50#c3
edit: i've re-read (*and understood*) it a bit more, and i think the whole thing is about not having to open an UDP port by yourself:
Although B's NAT will initially filter out any UDP packets arriving from C's public (NATted) UDP port directed at B's public port, the first UDP message B sends to C will cause B's NAT to open up a new UDP session keyed on C's public port, allowing future incoming traffic from C to pass through the NAT to B. Similarly, the first few messages from B to C may be filtered out by C's NAT, but will be able to start passing through the firewall as soon as C's first message to B causes C's NAT to open up a new session. In this way, each NAT is tricked into thinking that its respective internal host is the "initiator" of this new session, when in fact the session is fully symmetrical and was initiated (with A's help) simultaneously in each direction. -
not in all cases, as if other user uses same nick with the one you want to limit... and i'd see it being more acceptable, if it'd be done the way presented in the pic above...only per IP, then, it's cool too ;)
-
I dont have such tab (like 'IP' or 'user')you're right. maybe they will add such a column in the OP edition. they probably didn't put it here because you usually don't see anything else but IPs, unless the "searcher" (dunno the word) is in passive mode.
-
you're right on the fact that users with the same nicks can cause some trouble. but look for aSource->getUser() in ConnectionManager.cpp, you'll see this is used for the Pk, Lock, etc. so if this is used and considered good enough in all these places, it can also be used to identify the requester of a file, even if, i agree, it's not always correct when you have the same nick in different hubs.
about "the same user with different nicks in multiple hubs", this isn't much of a problem, he just has to choose the right hub where to ask for your list, and he might get the best one!
one could say there could be trouble on his side, getting "file not available" if his DC++ connects to you via the wrong hub. but this already happens if you use 2 clients with 2 different share on 2 different hubs, but with the same nick on each.
and in your links, i read about some "technical problems" for DC++ to handle different shares. this can be bypassed with the use of vectors/maps/lists/etc.
so your first point is still correct, but i would say "not that important" when you see there is a "hub" column in the transfer view, or in other views too; this "hub" column is usually filled with ClientManager's getUser(), which indeed does some guessing, but it's so widespread that i don't think using it one more time is really a problem.
-
I can never understand the discussions about speed limits. Use cfosspeed and you'll never have to worry about your upload affecting your download again, no need to use limiters.you're right, there are other progs too, i used to use BWMeter for such things. however, it's more convenient to limit a user based on his nick, so that it still limits him if he disconnects / reconnects and his IP changes, isn't it?
-
No. With NMDC protocol there is always the user guessing. The only way to actually tell which filelist to send, is for each share to have a specific port. So when they $ConnectToMe nick ip:port| you can tell from the port number they connect with, of which filelist to send. :fear:actually, i already did this and i never had to open multiple ports or anything.
i've changed nothing to the connection part, it's all in ShareManager'translateFileName. there, DC++ chooses which file to send as the file list; you have to give translateFileName the correct parameters so that it just has to pick the list corresponding to the parameter.
in UploadManager::prepareFile, i added the correct parameter to translateFileName this way:
ShareManager::getInstance()->translateFileName(aFile, aSource->getUser()->getTheShareToUseForThisUser());
there is no user guessing, because aSource->getUser() already identifies the correct user, with his hub, etc.
(btw, it's in a DC++ 0.401 based, so it might change a bit in ApexDC++, but something like this should still be possible )
-
this is how some versions of DC++ worked when TTH was first implemented, and it indeed was very cool. however, with the new versions which are very "TTH-focused", i'm not sure this can work, there are TTHs everywhere in every procol command. and with the new ADC protocol, it's even more.
however, if it was still possible do to so, i completely agree with your ideas ;)
-
Isn't it equal? If the file is much smaller, the saved bandwidth will compensate for the hosting space.it's so true, i didn't think about it... well... good idea, then!
here is how it could be done:
- the new .exe is hosted on a webserver
- ApexDC++ downloads an XML file, where it compares its own version with the .exe's version, which is given in the XML file. timestamps could also be used instead of versions. this new .exe can go to an "Apex.update" file
- ApexDC++ also downloads a small "update.exe"
- every time ApexDC++ starts, it checks whether there is in its directory an "update.exe"; if this file exists:
* if the file "Apex.update" is here, execute update.exe and exit;
* if "Apex.update" doesn't exist, delete "update.exe" and continue loading
- the update.exe file can be a simple command-line prog which tries like 10 times to move Apex.update to the old Apex.exe, if Apex.exe can't be accessed because it hasn't closed yet, pause during 1sec between each try.
once update.exe has finished (either the renaming worked, or it didn't, this doesn't matter), it loads "Apex.exe" and exits.
this is a scheme i use, so i know it works. there might be better, but it's the best i could find to fit to DC++.
-
I've now heard of a way to do this successfully with NMDC protocol.You'll need a TCP and UDP port open for each share you have.
Well that will work for active users, for passive users, erh, hmm, need to think about his one some more.
Or only make it available to active users that will pursuade more people to bother trying to become active. :fear:
i don't understand your point about the need of active and passive and stuff... don't you just have to create different file lists, and choose which one to use for each hub you connect to?
then of course, handle uploads and answers to searches correctly so that you don't answer to one hub's user you have a file while it's not in the list you have choosen for this hub...
-
As for the actual request, I don't think it's a bad one, although I don't mind the bandwidth much. If Crise is willing to do it and sees it as worth while then I don't think it could have any real negative affects, it's just going to take a bit of work.are you talking about your bandwith or the [website / server where the update file will be hosted] bandwith? (both might be the same, dunno...)
because IMHO, a whole new .exe at least will need to be hosted somewhere, and transfering it to every ApexDC++ user would take a lot of bandwith.
Ignore for all users (even OPs)
in Feature Requests
Posted
i don't think adding a listview to the settings dialog and reading / writing the corresponding settings is so hard and would need them to look at an existing source code...
but whatever, fulDC is here: www.fuldc.net