atit_ldce wrote:
>
> I have following scenario
>
> I have ps->direct comes to be DIRECT_NO for Request R.
Then you are using never_direct allow.
> now flow goes to peergetNeighbor() where neighborUdpPing() is callse to send
> ICP query is sent and ICP_SECHO is sent.
If ICP_SECHO is sent then you are using a non-ICP peer, pinging on the
UDP ECHO port instead of ICP.
> now entry->ping_status will be PING_WAITING.
Yes.
> now if ping time out occur then flow goes to peerPingTimeOut() from where peerSelectFoo() is called..
Yes, if your peer does not respond to the UDP ECHO packet.
> now if psstate->callback_data valid then still entry->ping_status will be PING_WAITING.
> so it will call peerGetNeighborReplies() again.
Not quite. peerSelectFoo() reads
} else if (entry->ping_status == PING_WAITING) {
peerGetSomeNeighborReplies(ps);
entry->ping_status = PING_DONE;
}
> assuming we get ping time out multiple times...
> doesn't it create LOOP.
There can only be one ping timeout per request. On timeout
peerSelectFoo() is called and the peer selection continues with what it
has, no longer waiting for further ICP/UDP replies.
Regards
Henrik
Received on Wed Mar 19 2003 - 02:02:36 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:33 MST