Page 2 of 2

Re: CCPM - Client to Client Private Message

Posted: 22 Sep 2013, 16:08
by poy
DC++ 0.830 has been released with this extension. example handshake:

Code: Select all

119 [In] 11.22.33.44:2000 (Hub <adcs://example.com:2000>): DNAT GYAA DD32 ADCS/0.10 1480 2168510784
120 [Out] 11.22.33.44:2000 (Hub <adcs://example.com:2000>): DRNT DD32 GYAA ADCS/0.10 51971 2168510784
121 [Out] 11.22.33.44:2000 (User [unknown]): CSUP ADBAS0 ADBASE ADTIGR ADBZIP ADZLIG
122 [Out] 11.22.33.44:2000 (User [unknown]): CSTA 000  RFadcs://example.com:2000
123 [In] 11.22.33.44:2000 (User [unknown]): CSUP ADBAS0 ADBASE ADTIGR ADBZIP ADZLIG
124 [Out] 11.22.33.44:2000 (User [unknown]): CINF IDABCDA4ST5DRMUX6AVWPWNWD2SBRT5PXQJAFABCD TO2168510784 PM1
125 [In] 11.22.33.44:2000 (User [unknown]): CSTA 000  RFadcs://example.com:2000
126 [In] 11.22.33.44:2000 (User [unknown]): CINF ID12343CGICZL4ZYOGHWXX7S557PQIJTMUTLE1234 TO2168510784

Re: CCPM - Client to Client Private Message

Posted: 06 Oct 2013, 15:43
by Pretorian
Below is a write-up (or at least what I think I've gathered) of the discussions here and on the hub.
=== CCPM - Client to client private messages
This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses a field in the (C-type) INF to signal that the connection should be used for private messages.

Implementations shall signal "CCPM" in the SU field of their (H-type) INF.

Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.

Implementations may choose if private messages shall be allowed in unencrypted connections. Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).

Removing the INF field 'PM' shall cause a disconnect of the connection (with an appropriate STA).

Implementations may decide what to do when the hub connection is lost during a private message connection.

Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Beyond that is up to implementations.

[options="autowidth"]
|=====
|PM |Field in the CINF to denote that the connection should be used for private messages. The field's value should be '1'.
|=====
Regarding the DI field, it's possible that there is a requirement to change it from
Any client that has this flag in the QUI message should have its transfers terminated by other clients connected to it, as it is unwanted in the system
to
Any client that has this flag in the QUI message should have its file transfer connections terminated by other clients connected to it, as it is unwanted in the system. Extensions may further limit non-file transfer connections.

Re: CCPM - Client to Client Private Message

Posted: 07 Oct 2013, 19:06
by poy
Looking good; here are a few points I can spot:

- "Implementations shall signal "CCPM" in the SU field of their (H-type) INF." > It's usually a BINF so I would change "H-type" to "hub-targeted".
- Add a note about the possibility of reusing a port on one end and only changing it on the other, as that isn't obvious as evidenced by the first posts in this thread.
- Add a note about the impossibility in the above port-being-reused case when going through NAT-T to then have a C-C PM and transfers at the same time.
- "Implementations may choose if private messages shall be allowed in unencrypted connections." sounds too sweet; I would give it some weight by strongly advising to encrypyt C-C PMs.
- The "PM" parameter of the "MSG" command is not required in C-C PMs.

There are a few novelties here regarding error handling that are probably not all implemented in DC++ - to be checked...

Re: CCPM - Client to Client Private Message

Posted: 07 Oct 2013, 22:20
by Pretorian
Changes, per above points and discussion.
=== CCPM - Client to client private messages
This extension adds support for private messages in a client to client context. The extension adds support for the C-type for MSG, and uses a field in the (C-type) INF to signal that the connection should be used for private messages.

Implementations shall signal "CCPM" in the SU field of their hub-targeted INF.

Implementations should differentiate between a C-C transfer connection and a C-C private message connection, so as to allow transfers and chat at the same time. The initiating client should issue a secondary CTM/RCM sequence to deal with the other connection. Implementations shall disallow GET (and other file transfer commands) in the private message connection.

Implementations are strongly discouraged but may choose to allow private messages in unencrypted connections.

Implementations may choose for which users that are allowed to send them private messages, so as to avoid spam (e.g., only trusted users, hub operators etc may initiate a C-C private message).

Removing the INF field 'PM' shall cause a disconnect of the connection (with an appropriate STA).

Implementations may decide what to do when the hub connection is lost during a private message connection.

Implementations should adhere to any requirements the DI field in the QUI command in BASE poses regarding non-file transfer connections. Beyond that is up to implementations.

The same port may, but needn't be, reused for a file transfer connection and a private message connection. Concurrent connections may be rendered unfeasible with extensions such as NAT-T.

The "PM" field of the MSG command should not be used in C-C private messages.

[options="autowidth"]
|=====
|PM |Field in the CINF to denote that the connection should be used for private messages. The field's value should be '1'.
|=====

Re: CCPM - Client to Client Private Message

Posted: 20 Feb 2014, 19:30
by poy
Sorry for the delay...

The above write-up is just fine. Nitpicks:
- "Implementations shall signal "CCPM" " > Implementations supporting this extension shall signal "CCPM"
- "Removing the INF field 'PM' " sounds strange to me gramatically (to be confirmed by an English expert :mrgreen:).

It should be noted that the released implementation in DC++ mostly adheres to this, except for error handling (does not send / care about STA, ignores INF updates regarding the "PM" field).