Dj_Offset's DCTNG

cologic · Post by **cologic** » 2003-07-01 00:12

Dj_Offset produced an interesting reworking of the DC protocol; it even lacks blatant spelling errors.

It:

Removes the silly lock/key system. Identifying clients is done with a command for that purpose, rather than hijacking a system that's spectacularly failed to keep unauthorized clients out of Hess's network.

Uses a challenge/response password system.

Identifies searches by a single-character ID so that when one person makes several searches, his client can distinguish between incoming search results from each.

Identifies people by a GUID, freeing up the nick from being an unreliable identifier.

Suggests regexp support in searches.

The first draft, unfortunately, doesn't include a client-client protocol. However, I find it an interesting proposal.

Dj_Offset · Post by **Dj_Offset** » 2003-07-01 04:03

The 2nd draft is here after some discussion with several people in the DC++ Developer Lounge.

Changes to search mainly aswell as UTF8 support etc.
I don't think regexp searches are realistic for extreme user counts, so those are removed. However mime and encoding types are included in the search request to be a more general purpose filesharing tool.

Sedulus · Post by **Sedulus** » 2003-08-06 11:11

I'd like to point out that one of the advantages of the protocol is - I think - that messages do not have to be modified (example: add someone's IP or prepend someones nickname), only validated, and since downstream never really is an issue, the extra bandwidth usage weighs up against the lack of (expensive) string operations.

cologic pointed out in the devhub that there's another modification would be nice. namely that non-broadcast messages should have a fixed place in the command so it's easily parsable. example:
To HISGUID Connect MYIP:PORT
To HISGUID PrivateMessage MYGUID blah blah blah
(a bit like CTCP(?) which I know nothing about...)
then you could also add through-hub-p2p extensions easily, and only validate (needed!) those commands that you know about.

about Full (3.3):
I don't know if this one deserves a whole command, and not simply be a parameter to another command, like Disconnect / Error / AccessDenied.
furthermore, I disagree that the protocol should force that hubs only send that at login. I can imagine situations where you would drop the least Ctm'd to user when a new one joins.

on the CRLF.. it would be way nicer to have CRLF than the current pipe (I'd even say LF on it's own should be accepted as well), but if we want hybrid hubs it would be comfortable to accept the pipe as well. at least, for DCH++ I could write a plugin that understands dctng, as long as all commands end with a pipe. of course this is due to the nature of how the plugin system is implemented on DCH++.
so does someone see an easy solution to convince the hub to start chopping commands at LF instead of the pipe (and would I need to bug arne to implement that ;) ), or, could the pipe and CRLF co-exist as command separators?

hm.. I think that's all for now ;)

ivulfusbar · Post by **ivulfusbar** » 2003-08-11 15:32

anyone happen to have a copy? somewhere? ;)) (the link is currently down)

Sedulus · Post by **Sedulus** » 2003-08-11 15:49

http://216.239.51.104/search?sourceid=n ... dctng.html
:P

ivulfusbar · Post by **ivulfusbar** » 2003-08-12 02:24

I don't like how Connect is done. As it is proposed now, its not possible to use multiple share in different hubs, i.e., it has the same flaws as the current DC-protocol. This could be solved if the client who sends Connect sends a random-string, which the other client has to respond with i nthe client<->client protocol.

Another new concept is "channels", similar to to IRC-channels or "a chat room". The reason for this is to ease the bandwidth load for userinfo, since the GUID would otherwise generate alot of traffic. After connecting to a hub a user may join several channels (limited by the server). The user will only receive userinfo for the users on those channels.

I think this will end up the other way around, i think most users will join several channels, and then probably get userinfo multiple times for each user and thereby increase bandwidth instead of saving it. And what about searchs? will they be sent only to users that or online on the same channels as you? or to all users in the hub.

waits-for-the-next-version-and-all-things-which-has-not-been-added-yet-ly'ers ;))