Subject: [ppsp] Comments for base tracker protocol and extended tracker protocol

From: "Fei Song" <[email-masked]>
Date: Fri, 19 Sep 2014 16:27:16 +0800

Hi all,
 
I have read the base tracker protocol together with extended tracker protocol and want to share some comments:
 
1.         Section 3.1, Last sentence: “This case requires a message to provide the ability to notify the tracker that a peer has left this tracker.” it might be better if just delete the “this tracker” at the end of sentence to avoid duplicate words.
2.         Section 4.2, Last one: “In such a case, the DISCONNECT Request message will have the same effect of timer expiring (STAT_REPORT), but providing a graceful disconnect of that peer from the system.” I think “a graceful disconnection” is more appropriate.
3.         Section 5.4, It might be clearer if two catalogs are given in this way:

(1)     Peer (with base protocol) vs Tracker (with extended protocol)
(2)     Peer (with extended protocol) vs Tracker (with base protocol)
 
No matter which situation the peer and tracker belong to, the compatibility issue could be found at the handshake state (via version number at header field maybe?). Then the “Unknown Messages” will be able to do the “double check” for compatibility.

Fei Song

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 19 Sep 2014 09:38:13 +0000

Hi  Fei
Thanks for those comments. Please see inline marked with [Rachel].
BR,
Rachel
From: ppsp [mailto:[email-masked]] On Behalf Of Fei Song
Sent: Friday, September 19, 2014 4:27 PM
To: [email-masked]
Subject: [ppsp] Comments for base tracker protocol and extended tracker protocol

Hi all,

1.       Section 3.1, Last sentence: "This case requires a message to provide the ability to notify the tracker that a peer has left this tracker." it might be better if just delete the "this tracker" at the end of sentence to avoid duplicate words.
[Rachel]: Will do.

2.       Section 4.2, Last one: "In such a case, the DISCONNECT Request message will have the same effect of timer expiring (STAT_REPORT), but providing a graceful disconnect of that peer from the system." I think "a graceful disconnection" is more appropriate.

[Rachel]: Good point.

[Rachel]: Yes, good suggestion.

No matter which situation the peer and tracker belong to, the compatibility issue could be found at the handshake state (via version number at header field maybe?).
[Rachel]: Currently, it can't since extended tracker protocol shares the same version number of base tracker protocol. That is because we don't think extended tracker protocol is a new version of tracker protocol comparing to base protocol. Instead, it's more like an extension of base protocol since it only extends some elements. And current tracker protocol has no handshake state for the sake of efficiency.

Then the "Unknown Messages" will be able to do the "double check" for compatibility.

________________________________
Fei Song