From DCppWiki

Jump to: navigation, search


Bandwidth Gain?

Hmm I read a bit through the ADC Protocoll and wondered, if there would not also be a huge bandwidth gain by introducing some kind of Deconnect function.. So that if a client wants a connection he sends the CTM/RCM just once and if he no longer wants something he sends the Deconnect... Quicksilver

  • Keeping that many connections open at one time is not very good with DC++'s threading model. People with large shares would have a very large thread count if everyone who had something requested got to stay connected. I do think the idea has some merits, however, especially in the context of an upload queue. - Pseudo
    • I don't see the difference for the threading... a client should just "imagine" he receives a CTM every 60 seconds from a user until he receives Deconnect from that user, so there is no need to keep the connections open...Quicksilver
      • There is no disconnect command, and how does the uploader know the difference between an intentional disconnection and one because of network problems? - Pseudo
        • What disconnect Command? If a user disconnects from a client it could be handled like before or not? And if a user disconnects from a hub, interprete a connection timeout or a received Quit like Deconnect. Where is the Problem? Quicksilver
          • User A queues file B from users C, D. A successfully downloads from C, but D doesn't know. How would you propose to handle this lacking a disconnect command? - cologic
            • After A gets a download from C, A could send a Deconnect to D? ... Quicksilver
              • Please, try to seperate implementation issues with protocol issues. The threading-solution is dc++-specific. The 60s timegap between connection attempts is also not defined in the protcol. fusbar
  • Please state what you mean by "deconnect" -- it's not a real word. --GargoyleMT 12:42, 7 Aug 2005 (EDT)
    • Yes sry for my neologism. At the Moment when a client wants something from another client he sends about every minute a CTM, the bandwidth used by this is large (especially when few slots are availabel..). So why not Send a CTM just once to a user.. This user connects then every minute as if he would receive Constantly CTMs by the other user. If a client would in the old way no longer send CTM he would now send instead this "Deconnect", to tell the other client that at the moment he no longer needs to connect. Call this "Deconnect" how ever you want, I just didn't want to mix it up with disconnect or sth else... Quicksilver
      • So you want a flag on CTM (to indicate to repeat it), and to introduce another hub command to cancel the repetition so you can save... 50 or 100 bytes of hub bandwidth? It doesn't seem worth it, since it's directed; any broadcast command will take up much more bandwidth. --GargoyleMT 16:33, 7 Aug 2005 (EDT)
        • Yes thats what I want to, save 100Bytes with an average nick another 100Bytes if it was a RCM, the Problem is that many users with full slots get CTMs by a lot of people and they get them over hours, in fact CTMs use more bandwidth then MyInfos(MyInfo+Userip Package is about 170Byte and you get less of these). The Bandwidth used up here may not play in the league of passive searches or searches in General. But now there is a new Protocoll so its now or never for this request. Quicksilver
          • Does ADC even say that it needs disconnecting when it gets a no-slot message? It seems to be currently specified as "53 Slots full", and I cant see any documentation for the severity value 5 saying you should disconnect. If both parties prefer to stay connected, that should be allowed. If any party doesnt like that, just disconnect and go CTM/RCTM again. This way no party needs to expend resources if it doesnt want to.
          • You have not understood the protocol at all. CTM is a 1-1 message. MyINFO search.. et.c. is 1-N message. In three hubs under my control, the bandwidth-use of CTM/RCTM is less than 0.10%. fusbar
            • If I have 100 users and 50k CTMs/RCMs while 1K MyINFO that seems to me like there is about the same ammount of CTM/RCM-Data thats how I understand it, but propably I am overestimating the CTMs because I just host small hubs. I thought in huger hubs CTM/RCM would equally rise like Myinfos, because the more sources(so indirectly also N-1), that may be a wrong assumption. Don't get me wrong I won't defend this, it just came to me it would be neat.. less work for the hub, though less security checks if CTMs have correct ip..less bandwidth. If you say its not worth the thing then its okay. Done, throw it away, sry to bother you. Quicksilver
              • Are those counts of the command, or the size of the command? fusbar provided some statistics about frequency of commands on a hub he has access to - it's in Hub Performance. It doesn't particularly prove or disprove your idea, but it takes an awful lot of directed commands to equal a single broadcast command. Plus, putting the onus on the uploader seems wrong and a potential area of abuse. --GargoyleMT 16:23, 10 Aug 2005 (EDT)
  • These were counts of commands sent, so even on this hundred user hub its still about 70% more myinfo data. And fusbars info seems to me pretty well disproveing my idea. Now, where would lie the positive aspects of it that are left? An upload list is no argument, that can be done with CTMs all the same. Onlyth positive things left is that if Multisource clients were standard it wouldn't cause any more traffic (or would even that not make a difference with CTMs?). Also we would have a protocol set intervall in which clients would try to connect, what seems to me rather positive for security. About the potential of abuse, I'd say rather not since the other client "awaits" a connect, slotlocking may still be the better way for fakers and simply not connecting could also be a reply on normal CTMs. Quicksilver
    • Well, any potential bandwidth savings would depend on if users transfer single files or multiple files, wouldn't it? If everyone transferred 200 megabyte files, there would be a reduction in CTMs when not using segmented downloads. However, if everyone downloaded that same file segmented into 20 megabyte files, there wouldn't be any appreciable difference between segmented transfers and non-segmented ones - at least not that I can imagine. Having a hub-set CTM time doesn't have much of a draw for me - how long before you'd want to expand that to chat, PM, search? And lag would make it non-exact anyhow. I think it's best left up to hubsofts to either delay or drop commands that come too fast - that will let them adapt to their available upload bandwidth - which is the real limitation anyhow. --GargoyleMT 11:19, 13 Aug 2005 (EDT)
      • Ah yes bad idea of me about the connection-time... I thought the ctms would make a difference because anyone who had already some sources would still send out CTMs to everyone else who has the file but who is maxed out. Don't know if this would make much difference, maybe a factor of 2 in Bandwidth for ctms, maybe more I don't know. Probably it won't matter. Quicksilver
  • There's not much bandwidth to be saved here since it's not a broadcast command. A presumed slot queue extension would avoid polling the CTM, but if someones interested in creating it remains to be seen ATD

Paths [resolved]

  • The draft doesn't mention that / is the path separator. --GargoyleMT 12:11, 20 Sep 2005 (EDT)
    • "The ‘/’ is used to separate directories" and the example of "The shared files are identified relative to the unnamed root ‘/’ (“/dir/subdir/filename.extâ€?)" seem clear to me... --Pseudo
      • Ah, I was relying on search too much. "Separator" doesn't occur in that body of text, and "separate" is used frequently enough in the rest of the document that it's a poor search term. I guess the person in Talk:XmlBZList must've missed it in a similar fashion. --GargoyleMT 14:40, 20 Sep 2005 (EDT)
  • Resolved then --ATD

Denial of Service Opportunities [resolved in 0.10]

Any user has access to all CIDs and all IPs. They can fake any packet to any user. This is a problem and has a few serious repercussions. This is specific to UDP C-C searches only.

  • Client DoS

If they fake a search of a broad enough topic, they can easily cause traffic multiplication of a factor 40 (see below). This should be more than enough to have users with even a limited upload to DoS any other user.

  • Hub DoS

By sending multiple searches all from one user, an attacker can exhaust any resource limit in the other users for this one specific user.

If the attacker creates searches from multiple users, the attacker could be able to trigger the total search reply resource limit of the clients in the hub. If one user's upload does not suffice, multiple clients can easily cooperate to do the same.


The multiplication term of 40 was determined as such:

A maximum of 10 search results per user [1] and a multiplication related to size:

A search request of the form:

USCH FCID TCID TO<token> ++<String>

results in an answer:


Search Length: 21 + sizeof(token) + sizeof (String)

Result Lenght: 73 + sizeof(token) + sizeof (size) + sizeof (filename+path)

Say we make the size of the token 8 bytes. we search for a small string, say in a scifi hub "star". Our search packet would be 33 bytes. The size of the replies are hard to determine. The filesize will range from 5-10 bytes: say we have an average of 7 bytes. Lets be gently and say filename+path are 50 bytes. This results in a reply packet of 130 bytes.

This means another reply multiplication of 4, easily!


  • Your point about Hub DoS isn't very clear - you don't talk about UDP active clients responding through the hub when the searcher is UDP passive, but that is integral to the idea of triggering flood protection on the hub. --GargoyleMT 12:06, 29 Sep 2005 (EDT)
    • The Hub Dos would be created by Client DoSing every user. You do not DoS the hub itself, only it's users. They can't do anything about it, nor can the hub. It requires a lot of bw or some cooperation with different clients. --Jove 07:23, 28 Oct 2005 (EDT)
  • The Client DoS is no real threat as a sound socket implementation will always simply drop excess UDP traffic. A continuous long-term attack could only reduce UDP search reliability on the network, which is questionable anyway at this point. --FarCry 16:32, 15 Oct 2005 (EDT)
    • It is a problem. If I can send out 100kbit of udp packets, you would get something close to 4Mbit of downstream traffic in UDP search results, coming from all users on the hub. Even if all the other users would limit the amount of traffic they would send to one user (and thus limit the max amount of traffic I could send your way), it would still be hard for you to get any search results from them since they are already dropping requests they think come from you (send by me). And although your pc might not crash, you will have 4Mbit of downstream bw less and your client will have to process ALL UDP packets that reach it to filter out the search results it does want. So you are in the hub, but cannot search and your downloads are seriously slowed down. If I would also send you searches coming from random users in the hub, those would use up your upstream bw too. --Jove 07:23, 28 Oct 2005 (EDT)
  • I believe this is a valid concern, I've changed the draft to warn about this and default to server broadcast searches in non-trusted environments. In trusted environments, this is still a valid bandwidth saver, and for example secure signing could make this a valid saver for semi/non-trusted environments as well, but that's for later...remove the resolved tag if you disagree. --ATD

Nick changes

Some propositions for the draft, regarding nick changes ("/nick") while staying connected.

  • Users should not be able to change nick to someone else's that is in the hub. The hub should return "STA 122" ("Nick taken") if someone tries to do this.
  • Users should not be able to change nick to a nick which is registered by the hub. The hub should return "STA 121" ("Nick invalid") if someone tries to do this.
  • Power-users (i.e. operators, hub owners or people in general with power) should not be able to force a nick change of a non-registered user. That is, not force a change for the non-registered user's nick to something else because the power-user want to have his/her nick. The hub should return "STA 122" ("Nick taken") if someone tries to do this. (This is ambigious if the first proposition is held firm.)

All status codes should be in the severity value of '1' as everything should be recoverable by the client.

Concerning if registered users should be allowed to change their nicks at all, is an implementation issue and doesn't need to be addressed in the specs. (That is, we don't need to discuss it here.) --Pretorian

  • Those are all policy decisions, and hubs should decide them. The ADC draft can make policy suggestions, but that's all it should do. --GargoyleMT 14:35, 4 Oct 2005 (EDT)
  • Well, in some way, this is already handled by the current ADC spec, no? If a client receives an error instead of it's INF reflected back, it should act accordingly...I'm considering adding a "nick reserved" error code though... --ATD

CID system broken?

The Client ID used throughout the protocol draft comes with several problems:

  • There is no incentive to stick to a single CID other than for the general benefit of the network. The well known "Nick Taken" or "ghost" situation is in fact only resolvable on the client side by changing the CID, unless the protocol offers alternatives. Changing one's CID regularly is also an easy way of reducing the number of overall uploads.
    • CID or GUID which it was first called (in DCTNG) was meant to be the new identifier for hubs, which means if you change CID you will not be operator on your hub until you register your new CID, which also means it will be impractical to change CID. If a user doesn't want to upload files there are several other ways to prevent this. The "ghost" situation is solvable on the hub side. --Dj_Offset 01:23, 28 Nov 2005 (CET)
      • The incentive to keep a CID by which you are registered is undisputed and I have no doubt that clients will support that by persistently storing it. The opposite situation arises for bans by CID, which makes functionality to change it on the fly or even automatically use a random one for each hub rather likely. I have yet to see a hub implementation that resolves "ghost" situations elegantly. --FarCry 16:16, 2 December 2005 (EST)
  • A persistent user handle (for managing favorite user preferences, like auto-slots) is not the same as a source handle for a certain file. One intention of ADC was to solve NMDC's shortcomings that prevented a single client from providing different shares on different hubs. Referring to user and source by the same value would be counter-productive.
    • That is why there is a "token" (or nonce) in the CTM command. Lookup the user and hub from the token. However using "VHOST" style shares was not one of the design goals behind the DCTNG initiative. --Dj_Offset 01:23, 28 Nov 2005 (CET)
      • How does the token (which is valid for a single connection attempt) relate to the favorite user status (which is persistent)? --FarCry 16:16, 2 December 2005 (EST)
  • The use of a single ID in each protocol command on all hubs suggests a global, long-lasting validity, which is hard to accomplish for a client and impossible to guarantee for a hub. As mentioned before, the only acceptable solution for a client to resolve CID conflicts is to generate a new CID for that specific hub. Therefor all client and hub software is forced to implement workarounds for situations in which a user's or source's CID differs across hubs and from local databases. This lack of reliability drastically limits the usefulness of the CID and lets the expense of 14 Bytes per protocol message look inappropriate. A much smaller local ID would be equally useful for a hub implementation and allow for a larger global ID (sent as part of the INF) range to reduce the chance of collisions.
    • This is a question about probability, practicality and bandwidth. In the first DCTNG draft we had a 160bit GUID, which means the chance of an accidental collition is 1 in 1461501637330902918203684832716283019655932542976. This was later reduced to 128 bit, and 64bit in ADC (still 1 in 18446744073709551616). The bandwidth cost of 64 bits is another story. In case of an intentional collition, well how is this compared to nick hijacking which we already have? CID does not provide a safeguard against this, but hub logins do. Besides a CID is probably longer lasting than nick names. How do you propose doing download queue management if not by using a "constant" CID, we already know how broken nicknames are for this purpose in NMDC. --Dj_Offset 01:23, 28 Nov 2005 (CET)
      • The chance for a collision is actually some orders of magnitude higher (you calculated the chance of someone else having your CID, not for an arbitrary collision) and would also be affected by the things I mentioned above (auto-randomization, CID bans). We also already had unintentional collisions in practice, because of a dc++ bug. However, I can't give you exact figures, but I know this: a wider ID is stronger and the current system compromises between strength and bandwidth-use, which is unnecessary, since there are alternatives. Most problems already exist with nicks being used for the same functionality (with the important difference that nicks are visible), of course, but the idea is hopefully not to create something new which comes with the same problems, but something better. --FarCry 16:16, 2 December 2005 (EST)
  • Most importantly, the CID (other than a user's nick) is a mere internal entity, which should be of no concern to the end-user. A client software can only hide that detail, if the specifications allow for a flawless implementation. While a user may easily spot certain nick changes (for example from "Bob" to "TheGuyFormerlyKnownAsBob") and understand and react to any problems arising from it, failure based on a mismatch or unwanted match of some invisible internal value is hard to resolve and will most probably result in frustration: Some download won't start although "Bob" is clearly online (he installed the client on a new computer, which gave him a new CID) or that new guy mysteriously always gets an extra slot (because he snatched a friend's CID and uses their auto-slot). A user's system drive may suddenly break and although he memorized his password, he can't recall the CID by which he was registered in all his favorite hubs...

Solution proposal:

First of all, the global identity of a client or user is of no significance for the hub's basic forwarding and broadcasting functionality. It imposes unnecessary depencies between network entities (clients and other hubs) which are not in control of eachother and therefor can't resolve problems in a satisfying manner. Instead of using the global ID for message routing, the hub should assign a local ID to each client connecting to the hub. A 24 or 32 bit wide integer should be sufficient for this. If necessary, this can be changed by a protocol extension. Variable-length encoding could preserve the message layout in that case.

The global ID should be divided into user and share/client ID, if the nick alone is not sufficient for the former. It (they) should be provided by the client as an INF field, giving it the opportunity to change it without disconnecting from the hub. The client ID should also be used to indicate the source in C-C UDP messages (alternatively, a combination of hub IP address and local ID could be used). This ID can have any desired width, because it has no impact on message lengths. A minimum of 128 bit would be recommended to further reduce the chance of collisions.

A future protocol extension could lay out rules for authentication of either ID between two clients or a hub and a client. This authentication mechanism can be networked together on a trust basis. Automatic registration upon the first login to a hub would subsequently harden the entire network against ID abuse and make it possible to build a credit system upon the global ID like other p2p systems already implement. --FarCry 18:13, 15 Oct 2005 (EDT)

  • What I proposed here actually solves none of the mentioned problems ;), but should enable backwards-compatible extensions, which then can improve things. Unless hubs and clients implement complex message translation functionality, the currently drafted system can't be used simultaneously with a different approach on the same hub. --FarCry 16:16, 2 December 2005 (EST)
  • So now from slow Quicksilver some questions about the ID system. Shouldn't we avoid sending a pid even to the hub? A hubowner could allways use etheral to look at the pid? Wouldn't it be better to replace the CID/PID with a RSA public key? Also your MAC address will change with your Hardware, so you would have to store the MAC address anyway, if you want persistency. Usernames have their pros in Identification, they can be remembered! How will you be able to reidentify a user that changed his system? How will an Op Connect to a hub that uses two clients and would therefore have duplicate MAC? So to allow this I am shure many Clients will soon implement a spoofing function as workaround. A public RSA Key would be truly unique and easy to verify, also could be used for encryption of PMs, singing of salted passwords... --Quicksilver

Unicode Normalization [resolved in 0.10]

  • The unicode standard defines different ways to represent at character(composed, decomposed). e.g the swedish letter Ã¥ this could be represented both as U+00E5 and U+0061 U+030A which looks the same when displayed. In case of ADC this could lead to problems in some areas, specifically the login process and searches. If the hub and the client stores the password in different forms it will result in different hashes which would lead to "unexplained" errors that users probably wouldn't understand. Searching could be resolved using a lexicographic comparison, but it would probably be more expensive than a regular binary comparison.
    • This is one of the things a CID would fix. -- Dj_Offset 01:26, 28 Nov 2005 (CET)

Solution proposal: The draft should specify a normalization form that should be used for all communication. From my understanding one of the forms NFC/NFKC would be best suited for this. I would propose NFC to retain as much of the original formatting as possible.

more info and sample implementation code

--Trem 16:24, 16 November 2005 (EST)

Normalization form C chosen. --ATD

Protocol extensions and feature announcement [Resolved in 0.10]

The signaling of support for certain protocol extensions in the current draft is handled by the SUP command, which is only meant to be exchanged between connected parties (message types C, H and I), which is sufficient as long as the negotiated feature relates to the current connection only (e.g. ZLIB compression). With REGX, the draft however already includes a feature proposal that affects routed traffic. A user could be interested in knowing how many other clients on the hub support that feature, to decide wether to search by regular expression or not.

There are other features imaginable, which would only be useful if a client knew about support for them before establishing a connection. Secure client-to-client connections are an example for that and judging from DC++'s source code, a new INF parameter has been introduced to transport the necessary information. I think we might run out of descriptive or fitting 2-character combinations very soon, if every potential extension gets its own flag. There's also a risk of two extensions using the same parameter ID accidentally, because their designers are not aware of the other feature. Therefor it would be good to standardize feature announcement through INF parameters with a defined set of fields. I would suggest using one field for enabled support (e.g. "S+") and one for disabled support ("S-") to allow for easy early processing or even processing without awareness of the respective feature (see below). The field ID should be followed immediately by a feature name of fixed length (FourCC) or a name that is separated from additional feature parameters by a specified delimiter (e.g. ":") for the same reason. --FarCry 21:20, 17 December 2005 (EST)

SU field in INF --ATD

Subscriptions [Resolved in 0.10]

Directly related to the signaling of feature support is the idea of broadcast subscriptions. It's not necessary to have them in the BASE specifications, but they can increase efficiency as an extension. A new message type could be introduced (e.g. S) that causes a broadcast of the command to all clients having a certain feature enabled. The feature name would be provided as the second parameter (after source CID) of the command. This way a regular expression search can be selectively forwarded only to the clients that can really process them (are supporting REGX). Or if a user doesn't want to unencrypted downloads, he doesn't have to search shares of users that don't offer secure connections.

Logical modifiers ("client does NOT support feature A") or even complete expressions ("client supports A OR (B AND NOT C)") would be nice, but can of course be left to an extension of the extension :). --FarCry 21:20, 17 December 2005 (EST)

  • qhub's already using the S type for server-only messages (to be sent to all hubs, but not to clients)... I'd rather not have to come up with a new letter :) --Pseudo
  • Type F added --ATD

Additional Error code, Required SUP [Resolved in 0.10]

I think there more then one thinkable cases where you may need this error and where i think "protocol error" isn't appropriate, because it's not specific enough. I would like to suggest the use of errorcode 44 as follows:

"44 Required feature missing, flag “FC� specifies the FOURCC of the missing feature."

--Pur 05:40, 14 January 2006 (EST)

Added. --ATD

Local/global IDs and added security [Resolved in 0.10]

Since I now see hope for a separation of hub-local routing IDs and global client IDs, I'd like to summarize the changes to the protocol which seem to be appropriate to me for achieving this:

  • The source CID should be removed from the default message layout and source and target local routing IDs should be part of type-specific message layouts. I- and H-type messages don't need information about their origin, unless the protocol is meant to function in a connectionless scheme. The source CID is already redundant in the current draft, and routing IDs just make it a little more obvious.
  • The login procedure can stay at the same amount of round-trips, but there has to be a point at which the local ID for a connecting client is assigned by the hub. There are three possible solutions:

a) The hub sends the local ID of the client as an INF field in the first IINF. b) The hub sends one additional command (SID, for example) for this specific purpose only. c) The first client INF uses message type H and thus doesn't have to contain a source ID. The client figures his ID out from the BINFs, identifying his own by matching them against its global ID. Its local ID is the source ID parameter in that message. I dislike option a) very much, think that b) is acceptable, but favor c).

  • The INF needs one additional field for the global ID. I suggest "ID" for the parameter name. The global ID should be 192 bits binary as this makes accidental collisions very unlikely and is also the size of a standard Tiger hash (see below).

The local ID could be 20 bits wide for a zero-overhead base32 encoding or 32 bits wide for the smallest usable power of 2. I'm not sure which is better.

With this we get rid of the compromise between bandwidth cost and global ID size that the current CID system suffers from, but there's more: The 192 bit wide global ID could in fact be a hash over the client's identity data, effectively hiding it from other clients. In addition to the ID field, the client also provides the data from which it was generated in its initial INF to the hub. The hub would then check if ID and identity data match and strip the field from the INF before forwarding it to other clients (yes, intrusive, but it already does that with "OP", "HI" and "I4"). The hub would thus be the only entity a client would trust with its actual identity data, making it impossible for other clients to steal it. This may as well be defined as an extension to the more basic local/global ID system, but is simple enough to make it a BASE feature.

The identity data ("PP" for pass phrase?) could either be a variable-(but minimum-)length string of printable characters or base32 encoded binary data of a fixed size.

There's unfortunately no similarly easy way to remove the client-hub trust relationship as well, but extensions that introduce a third authentication party would fit in seamlessly, as (based on SUP) the client could simply replace the field with its identity data with one that contains information on how to verify the ID alternatively. --FarCry 18:46, 20 January 2006 (EST)

Fixed --ATD

Inconsistencies between the draft and dc++

I think by following the current draft, it's impossible to send a Private Message in the name of the hub. The MSG field needs a PM<group-sid> flag to send a PM. But the hub has no SID. In fact, DC++ and ADCH++, and I think other softwares too use AAAA as a hub-sid, but it's specified nowhere, thus it's not a good idea to use that for PMing, since nothing guarantees that the client will receive it and can process the message. Despite of this, DC++ has a new "Ignore private messages from hub" option, which looks like a feature called for life by ADC. -- FleetCommand 10:02, 20 October 2006 (CEST)

You are mis-interpreting the meaing of a private message. A PM-field in a MSG means "send this message to a group or to a 'new' window (not main chat)". A private message means "send this message to only that user". Look at D and E without a PM-flag; The message will be only to one user, but will (should) appear in main chat. (Whether DC++ do [or not do] that, I don't know.) Pretorian 17:08, 8 December 2006 (CET)
I'm not mis-interpreting. The meaning of a "Private message" is a "message in a new window, which is not the main chat" for me :) So you can see it's impossible to send a "message in a new window" when you're the hub. Despite of this, there is an optioin to ignore them in DC++ -- FleetCommand 19:46, 8 December 2006 (CET)

AJAX for chat/status/control ?

I know this would mean a complete rewrite, and am really not expecting answers, but i'm postulating the question just in case someone finds it useful.

How 'bout separating dc in two? one part being the transfer engine, using plain old dc to setup and maintain transfers, and AJAX to send the filelist, communicate with the server, and for remote control too. On the other hand there would be an ajax GUI, accesible from a web browser, that allows users to chat, pm each other, do searches, browse filelists and add files to their queue.

some major advantages of this system would be:

the posibility of extending dc: since AJAX is extensible by definition, nothing else needs to be said.

taking load off the server: typical user and op commands (+whois, +kick, etc) are sent as text to the server, wich then must parse, validate and execute the command; causing a lot of server load (especially when the command has an invalid syntax, 'cause it must be resent, reparsed and revalidated). With AJAX validation could occur on the client, taking no load from the server. Then the command can be parsed into binary code and sent to the server who only needs to execute it, and as it is in binary format, execution would be extremely quick compared to old dc. Then the answer could simply be an index for an array sent to the client upon login, which would allow the full text answer for the command to be displayed after sending only a byte of info. Much less server load.

There are a lot more advantages but i'd like to keep it short. If you wish to take this direction, say so in here and I will more than joyfully help with the designing and development of the ajax side of the app

Best regards —The preceding unsigned comment was added by (talkcontribs) 16:24, 24 November 2006 (UTC)

Is it safe to move validation of privileged commands to the user's end? I also suspect you're overestimating the cost of parsing/validating those commands. AJAX may have its place, but I don't know if those reasons are the best for using it. --GargoyleMT 01:55, 28 November 2006 (CET)
Hi! me again
what do you mean with validation of privileged commands? if it is that privileged commands could be faked from the user's side then maybe I didn't explain myself well. with validation I meant syntax validation, and besides, since it would be coded in ajax their wouldn't be any knowledge on the user's behalf of the commands, because the commandlist aswell as the syntax validation instructions would be sent to the user according to his priviledges, upon logon. And i'm not overestimating the cost of validation/parsing in that the message sent would weigh much less than the oldstyle dc way of sending stuff. If you think this isn't an issue then try setting up a dc server on a 512 DSL line =).
If you wish to further learn about how ajax (when properly coded) would help take the load off the server, then checkout This is an online operating system, and their demo server serves about 70000 users worldwide from a pentium MMX 233 mHz server in spain (with 512 MB of RAM)
Greetz!--Tijuana 01:20, 2 December 2006 (CET)
I'm not familiar with AJAX, but the point is that hubs have to provide for client misbehavior and attempts at (protocol) abuse. If AJAX can cope with that, good. If so, you'll probably want to petition Arne directly. There have been changes to ADC since the first draft was published, but nothing that extensive. There are some 3rd party clients and hubs now too, so if you want it changed, lobby for it before too many implementations pop up. --GargoyleMT 14:51, 6 December 2006 (CET)
Forgive my ignorance, but how would I contact arne and/or lobby for this? --Tijuana 19:38, 18 December 2006 (CET)
Email him. His email address is in the header of each file in the source code, and you can also use the contact form on the Sourceforge project page and/or guess it from his user name there ( --GargoyleMT 15:09, 19 December 2006 (CET)

ADC Hublist format - Country codes

If i think of it, it would be better if xml hublists would use a two letter country code (as specified in ISO 3166-1 alpha-2) and perhaps aswell the exceptional reservations (eg.: XI could stand for International) that would enable clients to have tranlate the code into the language they want (as far i have seen its almost always just the english country names) and perhaps a minor merit that the size is lesser. Ketsuron 17:11, 27 January 2007 (CET)