Extending ADC's C-C with MSG

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
ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Extending ADC's C-C with MSG

Post by ullner » 2006-12-25 11:15

The current ADC draft specify that MSG is only valid in C-H and H-C. This mean that two clients can never speak with each other *really* privately. I am proposing adding an extension to ADC that would allow MSG to be availble in C-C.

I don't consider that there is any other type that would be benificial to have in C-C, which is why I'm not going to advocate for them. However, the point with this thread is to come to a common conclusion about what this extension should do, so make suggestions if you want.

ECM - Extended Connect to Me
ERM - Extended Reverse connect to Me
Contexts: F, T
The syntax for ECM and ERM is the same as for CTM and RCM.
Additions in ECM and ERM:
  • * MSG is allowed
    • * No SID as parameter
      * No PM flag
Flag ECM1 for ECM support, version 1. If you support ECM, you support CTM and ERM. Flag ERM1 for only ERM support (version 1). You may flag CTM and ERM. (That is, you don't need to support the extended active connection, but can support the extended passive one.)

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

Post by Dolda2000 » 2006-12-26 21:48

Are these new "ECM" and "ERM" commands really necessary? I don't see any complications that could arise from just using the normal CTM or RCM commands.
If ECM1 (is that flagged in SUP or INF, btw.?) is flagged, MSG is supported in C-C, otherwise not. I would guess that is really all information that would be necessary, no?

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2006-12-27 12:15

After discussion with cologic and Farcry, I believe Farcry's suggestion for C-C MSG is the best.

His suggestion was to use a different protocol identifier in CTM/RCM. Eg, CTM CCMP/1.0 port...
Where CCMP/1.0 mean Client-Client Message Protocol (version one). CCMP/1.0 should be fully compatible with ADC/1.0.

What about my suggestions to remove the SID and PM flag?

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

Post by ivulfusbar » 2006-12-27 13:08

Allow MSG in C-C context.

Problem solved.

Close thread! ;))
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

FarCry
Programmer
Posts: 34
Joined: 2003-05-01 10:49

Post by FarCry » 2006-12-27 13:15

His suggestion was to use a different protocol identifier in CTM/RCM. Eg, CTM CCMP/1.0 port...
That is only if there is a need for the hub to see what the connection will be used for. I still think we need no difference in CTM/RCM at all for that functionality.
Allow MSG in C-C context.

Problem solved.

Close thread! ;))
C-C messages are not necessary for basic chatting, but mandating support for this in the BASE protocol complicates client implementation, which is why I think it should be an extension.

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

Post by ivulfusbar » 2006-12-28 02:49

Since MSG never requires a valid response from the receiving client. I would consider it as part of BASE that you don't have to implement if you don't want to. All you have todo is to silently drop the message and not send back a STA.
Everyone is supposed to download from the hubs, - I don´t know why, but I never do anymore.

ullner
Forum Moderator
Posts: 333
Joined: 2004-09-10 11:00
Contact:

Post by ullner » 2006-12-31 08:19

FarCry wrote:
His suggestion was to use a different protocol identifier in CTM/RCM. Eg, CTM CCMP/1.0 port...
That is only if there is a need for the hub to see what the connection will be used for. I still think we need no difference in CTM/RCM at all for that functionality.
For the client, it would be much easier to see "CCMP/1.0" and know the connection will be (only [if we decide the extension should only allow MSG]) used for chat. If the client uses this scheme, it doesn't need to check the other client's feature set. (Though, it probably should.) If the hub doesn't allow CCMP/1.0, the client can "simply" use the ADC/1.0 approach, you, Farcry, want. (The hub could of course also filter the feature set sent, which forces the client to act in blind.)

I will most likely implement, in Elise, the CCMP approach (it will of course also notify with the INF SU). If arne decide to implement the C-C MSG feature in a different way, Elise will follow. But until then...

Locked