Disable, Emulation by Default

[Lotus 0]

You know, Apex can be spotted even when emulating... and it will even more so when we merge some changes from SDC. If the hub owners are too lazy to figure out how, then sorry no cookie for them

You say emulating is cheating if that is the case then do something about it, don't expect us do it for you. Because we obviously do not think that emulation is cheating (since if we did that option would have been removed ages ago).

I want to be clear about this. I like Apex (and Strong and RSX actually). I allow all clients in my hubs. But my sincere opinion is that you use emulation, at least partially, to override some client bans. This is a simple point. Now, there might be other ways to ban Apex, but still emulating will make ApexDC shown in more hubs than the alternative to not emulate. From curiosity, in the beginning, why was this option ever created?

Anyways, could you perhaps give me a list of reasons why DC++ 0.75 (since that is the version we "emulate") should be allowed in a hub and Apex shouldn't... I am more than interested in hearing these reasons. If you are unable to do this then the whole discussion about emulation going on in here is pointless (since I don't even consider changing anything if the reasoning behind it is "just because").

You are wrong. You are saying: the client we emulate is inferior so this means we don't emulate. But your logic is faulty. And if I give you a reason as you ask, will you then change the emulation to DC++ 0.69 for example ? This way you can skip any of my reasons, according to your logic presented here...

The real issue is this, imho: it does not matter if you emulate something better or worse. And, for God sake, if DC++ is not better, why do you still emulate it ? Please just answer this question. You all argument that emulating is not wrong, but until now, nobody gave me a direct answer WHY emulating. Just why ?

The point is not that DC is superior or inferior to Apex. The point is the purpose of emulation. And I think this is to gain access to more hubs.

At least BM argumentation that ApexDC is DC++ with some extended features is better then yours and I can accept it to some degree. But still the question remains: why emulate ? Toast also admitted somehow, only said that this option is necessary for future development of the DC. But your argumentation, that DC is not better then Apex, don't stand. You don't cheat to look better. You cheat to gain access.

I like your clients and I think you are doing a great work for the DC community. Not words. I do think this. But this does not mean that I will not sanction you where you are not playing fair. And I think you are not here.

[Lotus 0]

Also people should realize that there's no emulation. Since original NMDC client doesn't have any tag, it's a bug in NMDC hubsoft implementation if it detects clients by tag. Tag is only a part of description where user with original NMDC client can write what he wants.

This are technical things. You can use technical specifications but the reason of emulation remains. You are not playing unfair because you are violating the DC protocol. Not because of this. As it seems, you have found a "legal" way to do it (to play unfair)...

There is no emulation, but we still emulate. Or at least, use 2 alternatives for the tag... with the effects they have... :blink:

[Big Muscle 1]

So you want to say that original NMDC client violates its own NMDC protocol, because it allows user to write any tag he wants?

[Lotus 0]

No. But I am saying that the way this "tag" evolved, you are using it today to identify yourself in different modes, in order to gain access to hubs that don't want to let you in. This is not fair. There is no technical specification, but this is what you are actually doing.

If you mean what you say, why don't you let me change the tag *ANYWAY I WANT* ? And why DC doesn't let me do this also ? What was the purpose of the tag when it was created ?

[adrian_007 0]

bm, but why hubsofts would restrict VE field? it's pointless, and afaik atm there's no such hubsoft. imo while merging to adc, we should say what's right and what's wrong in this mess - instead of banning for VE owners should ban ie. for low slotratio etc.

if this won't happen, adc will be next broken nmdc with less bugs...

about rsx++ and tag thigy, when using emulation it append user's description with short tag.

[Mek 13]

Today's DCGUI (Linux DC client) lets you write anything into your description. So if you want, you can write your own tag there (this is called tag faking). The tag is not part of NMDC protocol specification. But since some time it is used to identify clients (and check for slot count, hub count, connection mode and much more). To keep it backwards-compatible, the tag became a part of user's description in the protocol (hence the name "description tag" in some hubs/clients).

Emulation lets you enter hubs which have banned ApexDC++. The reasons are silly - such as segmented downloading or upload limiting capabilities - the hub leaders think Apex is just another fake client and thus ban it along with TRUE fake clients like RSX++ and Zion. But hey, times are changing, it is much better nowadays than some years ago.

Faking your tag is NOT okay and you will get banned in most hubs for doing it. Faking the tag means writing your own one - stating that f. ex. you are only in one hub and have 5 slots opened but you are in 20 hubs and have only 1 slot (this will get you into even more hubs).

Emulation means changing client identification - the part of the tag where client identification string resides - and it is OK :D

[Big Muscle 1]

Lotus: No, it's not what we are doing. We just follow protocol specification and update user's description according to user's choice. Since there's no tag in NMDC, we give user a choice whether to attach "core version" (ApexDC++'s core is still only DC++ 0.xxx) or "client version". If hub doesn't want ApexDC++ to enter, it should use proper means to detect and not restrict clients by user-settable field. It's hub fault. (If you still don't understand, just imagine what happens when user with original NMDC client sets its description to something like "<ApexDC...>" (protocol allows it; if hub doesn't allow it, it violates protocol). He will be banned for using ApexDC++ although he doesn't use it. It only shows that hubs use invalid mean to detect clients).

adrian: the reason is same why NMDC hubs restrict user's description field. The difference is that ADC's VE field is really designed for client identification while NMDC's description field isn't. True, there's no such ADC hub today, but it may be because there's no "really usable" ADC hubsoft at all ;-)

[Lotus 0]

Emulation lets you enter hubs which have banned ApexDC++. The reasons are silly - such as segmented downloading or upload limiting capabilities -

If I ban Apex in my hub, silly or not, *it is my decision* and it is my hub and I SHOULD BE ALLOWED TO BAN WHAT I WANT. You should not force your way in. This is where you are not playing straight. You say it is silly but since when do you decide for me ? This is how the political leaders are listening to my phone and mail... for my own good. Let me rule my hub as I want, considering I do nothing wrong (like flood or something).

Lol, I can't even tell how many people in my hub are using one client or another... It's a mess.

[Lotus 0]

Lotus: No, it's not what we are doing. We just follow protocol specification and update user's description according to user's choice. Since there's no tag in NMDC, we give user a choice whether to attach "core version" (ApexDC++'s core is still only DC++ 0.xxx) or "client version"

Why do you give the user such a choice ? Who came up with this idea and why ? Why not just use Apex ? What is it's purpose ?

Of course you know protocol better then me and technically speaking, you are correct. But of course you know that the interpretation of this TAG is as it is, and knowing this, you use this interpretation to gain access to more hubs.

No, it's not your fault, it's hubs fault they interpret TAG the way they do. But then, what was the purpose of this dual description ? And if it is not a rule, if there is no specification... what about the other fields from the TAG ? What about share, slots etc ? There is no specification there either. So you don't let me to change that parts because I would disrupt the DC very badly (and I 100% agree) but on the other part, you change the "client" description in tag as you like.

You say the hub should not interpret that part of the tag as the client, since there is no proper specification for this anywhere. So I am asking you: what do you think about the other parts of the tag (slots, share etc) ? Should the hub take them into consideration and for example ban a user because the tag shows he has no share at all ? Or not ?

The tag is the same but you are interpreting it differently depending on how do you like.

[Crise 26]

You are wrong. You are saying: the client we emulate is inferior so this means we don't emulate. But your logic is faulty. And if I give you a reason as you ask, will you then change the emulation to DC++ 0.69 for example ? This way you can skip any of my reasons, according to your logic presented here...

At least BM argumentation that ApexDC is DC++ with some extended features is better then yours and I can accept it to some degree.

I never once said something is inferior (or superior) to to Apex nor vice versa. I didn't even raise a real argument... I just asked a simple question. I'm not so cheap as to neglect valid reasons, like you seem to think... but I have yet to see any other reason, from you, besides "just because".

I never change the DC++ version we send while "emulating" it stays as it comes from StrongDC++ (and is thus only updated when merges happen).

Emulation lets you enter hubs which have banned ApexDC++. The reasons are silly - such as segmented downloading or upload limiting capabilities - the hub leaders think Apex is just another fake client and thus ban it along with TRUE fake clients like RSX++ and Zion. But hey, times are changing, it is much better nowadays than some years ago.

First, RSX++ a cheating client? How so?

Now here we have reasons, real ones, and here is what should be noted, for future:

1. DC++ 0.75 already does segmented downloading (some form of multi source too these days, unless I am badly mistaken).

2. Bandwidth Limiter is already in DC++ svn trunk (albeit it has a bug or two to work out) and that trunk version still identifies itself as 0.75 (for now) I think, but this I need to check.

[Lotus 0]

I never once said something is inferior (or superior) to to Apex nor vice versa. I didn't even raise a real argument... I just asked a simple question. I'm not so cheap as to neglect valid reasons, like you seem to think... but I have yet to see any other reason, from you, besides "just because".

If Strong and Apex will no longer allow emulation, this will have some interesting (generally positive) effects on the DC network itself. Hub operators will start to think. Some hubs that are ruled by stupid people will probably lose users. ApexDC and StrongDC will not not lose users in the long time. It is a long time since ApexDC and StrongDC started and you should state your position. This is not a secondary position. It is a top position, for both Apex and Strong. Sooner or later, this step must be done, imho. It will also make things more clear, like each user what client uses. If it does not happen, you can emulate again. Worth to try.

[Big Muscle 1]

Lotus: tag has been made for information purposes only. Of course, hub has right to ban client according to this tag. But... it should specify the real reason of ban. It's correct "You have too many slots in your tag. Correct it." when "S:9999" etc. Also it's correct "You have invalid/non-allowed tag. Correct it." for "<ApexDC...>". So, user should be able to correct it so he can enter the hub. (And because it is user settable option, he can change <ApexDC...> to something different - the same as he can change slot number S:9999 to S:3).

What I only want to say is that using tag to detect client is bad option and it's not cheating when user is allowed to change the tag. Or is it cheating when user sets 3 slots and not 4?

[Lotus 0]

Ok, you have convinced me. I eagerly await the version of StrongDC that will allow me to change slots and other info also... :)

[Big Muscle 1]

You don't have to wait for anything. This change is allowed since the first version of DC++ :)

[Mek 13]

First, RSX++ a cheating client? How so?

Sorry. I meant the unofficial one used mainly by some operators in Central Europe.

[Lee 84]

Sorry. I meant the unofficial one used mainly by some operators in Central Europe.

Psh, stick to official ones for arguments sake. :)