New protocol draft

Technical discussion about the NMDC and <a href="http://dcpp.net/ADC.html">ADC</A> protocol. The NMDC protocol is documented in the <a href="http://dcpp.net/wiki/">Wiki</a>, so feel free to refer to it.

Moderator: Moderators

Locked
Dolda2000
Posts: 20
Joined: 2003-11-12 20:11
Location: Täby, Sweden
Contact:

New protocol draft

Post by Dolda2000 » 2003-11-12 20:20

Is anyone up for a draft on a new protocol which isn't as braindead as the orginal DC protocol, and which can gradually take over the orginal protocol?

I'm thinking something like the following features:
Regexp searches and tagged searches
Encryption
i18n (Unicode nicks, chats and so on)
A sensible syntax
No locks/keys
Substream/proxy support
Feel free to add to the list.

The thing is that I've just started rewriting my Linux DC client (ie. I won't compete with you...), and I would like to implement two protocol modules, one for the DC protocol and one for a new, good, protocol that includes at least the above features. However, since most DC users are Windows users, I was thinking it would be best if I could get a big project like DC++ with me on it, or it is likely to remain unused.

If anyone's interested, please say so, and I will spill my mind a bit more. =)

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2003-11-13 04:39

Have you seen DCTNG?

Dolda2000
Posts: 20
Joined: 2003-11-12 20:11
Location: Täby, Sweden
Contact:

Post by Dolda2000 » 2003-11-13 11:27

No, I hadn't. Thank you very much for that link!

Cloyd
Posts: 8
Joined: 2003-06-30 04:11

Post by Cloyd » 2004-03-03 15:32

i think it should be added some new form of passive search... it could be done easily without taking apart all the DC proto. It could be done somehow like other p2p programs do (kazaa with fasttrack network for example).
(90% of all the bandwidth consumed by dc is because of the bad handling of passive searches...)

entities envolved: Server, 1 Passive client, 1 Active client

We may introduce 4 new commands like (parameters omitted: $n_passSearch..., $AProxy..., $AProxyDenide and maybe $PassSearch... or something like these).

the first ($n_passSearch...)
SERVER -> PASSIVE: should be sent by the server to the passive client to inform him that he won't receive any result from the server but it will receice all from the active client specified in the command.

the second ($AProxy...)
SERVER -> ACTIVE: should be sent by the server to the selected active client to inform him that he'll do the dirty job... The active client will receive all search results and it will forward them to the passive client.

the third ($AProxyDenide) OPTIONAL
ACTIVE -> SERVER: should be sent by the selected active (search proxy) client to inform that it rejects the dirty job (because of some problems or some timeout settings on the client).

the fourth ($PassSearch...) OPTIONAL
PASSIVE -> ACTIVE: should be used to create the link between the active client and the passive one. Here we could use also the one we usually use to request a search to the server.

STEPS:
- at the passive client login he sends $Support with a new parameter which can be NEW_PSEARCH to inform that it supports this new search method.
- the passive client sends the search string to the server in the usual way.
- the server selects (with some methods... maybe with priority on active high speed clients) an active client and informs him that it will be a "search proxy" for the "passive client".
- the active client could deny the server job because of some problems (...)
- the server informs the searching passive that it will receive all search results from the active client (the one who didn't reject to be a proxy search server)
- the passive client connects to the active client
- now the server can send the search string to all connected active clients and tell them to reply to the selected active client.

It's just a proposal... maybe it misses something but if it could be done it will be a great leap forward... less bandwidth consumed for all! :)
i hope it will be taken into consideration and it will be incorporated in dc++ && || in dch++.

Sorry for my bad english... i hope you got it all the same! :)

cologic
Programmer
Posts: 337
Joined: 2003-01-06 13:32
Contact:

Post by cologic » 2004-03-05 01:59

I should probably mention that ADC looks somewhat likely to become eventually adopted, so one should probably be aware of it whilst discussing DC replacements.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2004-03-05 09:59

A short comment:

Hubs doesn't have such a bad issue with search replying as people think for passive searches. Its broadcasting the search-requests that uses the most bandwidth. All auto-searches et.c. will not consume much bandwidth in $SR. They constitiute more than 95% of all search-replies. Same will happen with hashes since they will only reply for exact matches. Its better to start to look at distributed hubs instead of trusting clients in my oppinion. But sure, passive people searching for "xxx" will generate alot of answers in most hubs since XXX is the driving force of most internet-applications ;)).

some-short-comments-to-your-thoughts-ly'ers ,))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

mythdl
Posts: 12
Joined: 2003-09-07 03:11

Binary protocol

Post by mythdl » 2004-03-16 00:26

It would save alot of bandwith to use a binary protocol like most other major p2p networks. This could save a lot of bandwith.

EG instead of $Search <clientip>:<clientport> <searchstring>
you could use an 1 byte OpCode to represent the $Search, 1 or 2 bytes to show the length of the search string and then the search string istelf, and 4bytes to represent the IP and 2 bytes for the port.

This would save a lot of bandwith, and the commands would be easier to process, saving CPU and RAM usage.

ivulfusbar
Posts: 506
Joined: 2003-01-03 07:33

Post by ivulfusbar » 2004-03-16 02:30

A binary protocol has been rejected by the majority of developers in the community. Easier to process is not an issue since hub-softs are not CPU-bound. Parsing messages in a hubsoft uses up a neglictable amount of the cpu.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

dR slIzer
Posts: 2
Joined: 2003-06-21 05:10
Contact:

Post by dR slIzer » 2004-03-16 12:03

A binary protocol is not the way to go in my opinion, it may spare some bandwidth but I'm sure it will raise other problems.

Something I should want is a fully encrypted protocol. Using a SSH-like encryption should work I think because it's secure as hell ;)
The Knoppix 3.2 boot: ERROR only one processor found

Locked