[ppsp] 答复: FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

["Huangyihong (Rachel)" <[e-mail]>]

Hi Arno,

Please see inline.

Best regards,
Rachel

-----邮件原件-----
发件人: Arno Bakker [mailto:[e-mail]] 
发送时间: 2013年7月30日 19:31
收件人: Huangyihong (Rachel)
抄送: [e-mail]
主题: Re: [ppsp] FW: New Version Notification for draft-huang-ppsp-extended-tracker-protocol-03.txt

Hi Rachel and all

please see inline.

On 30/07/2013 12:43, Huangyihong (Rachel) wrote:
>
> "1. The peer list of a specific swarm obtained by a peer may be out of 
> date":
>
> I always assumed that when the initial peer list received via the base 
> protocol is outdated, a peer would send a new CONNECT message with a 
> PeerNum attribute to get a new list. So why is extra support needed?
>
> [Rachel]: I think the peer should first disconnect from the swarm, and 
> then send a new CONNECT message to get a new list. Actually, I think 
> this procedure is more complicated than having a new message ( in this 
> spec, we define a new message FIND) to deal with it.
>

I may have been misreading the base protocol spec for a long time then. 
Table 8 of the base protocol indeed does not list that a "CONNECT action=join" while in tracking state is a valid transition. IMHO, I think it should for both LEECH and SEED, retrieving a new set of peers for the swarm you are in is basic functionality. Or FIND must be moved into the base protocol spec.

[Rachel]: All right. Let's see how it works in the meeting.

> "2. A peer may have the requirement to inform the tracker its new 
> network address when the peer has changed its primary network 
> attachment."
>
> a) Isn't this the role of mobile IP? and b) can't the base CONNECT 
> handle this?
>
> [Rachel]: I think this case is talking about the peer switches its 
> network address during the streaming. For example, a peer is firstly 
> using WIFI to connect to the tracker. But during the streaming, the 
> WIFI has problem and the peer decides to switch to a wired network but 
> it doesn't want to stop the streaming. Actually, I think the base 
> CONNECT can't handle it. Because it can't "CONNECT" to the same swarm 
> twice, right?
>

There are many IETF drafts to deal with IP-address change, and IMHO there is no need to add another one here.

[Rachel]: I think this case is similar to the first case, because first case is about getting the update information from the tracker to peer, and this one is about providing the updated information of the peer to the tracker. So the conclusion made to the first case could also apply to this case.

CU,
     Arno