Richard
I apologize for the late reply. I think that your proposal makes sense
and I would like you to go ahead and implement this.
Cheers Luca
On Apr 9, 2008, at 1:55 PM, Richard Andrews wrote:
>
> OK - I see what you are trying to do but I think it is still broken.
> update_peer_address() changes the peer address even if when==0. This
> is
> probably my fault. At any rate I think this code needs an overhaul.
>
> Here is a proposal for how I think this should work. If you agree,
> I'll add the
> design to HACKING and implement it.
>
>
> Edge Registration Design
> ------------------------
>
> * Send REGISTER on rx of PACKET or REGISTER only when dest_mac ==
> device MAC
> (do not send REGISTER on Rx of broadcast packets).
ok
>
> * After sending REGISTER add the new peer to pendingRegistration
> list; but
> * Don't send REGISTER to a peer in pendingRegistration list
> * Remove old entries from pendingRegistration at regular intervals
> * On rx of REGISTER_ACK, move peer from pendingRegistration to
> known_peers for
> direct comms and set last_seen=now
> * On rx of any packet set last_seen=now in the known_hosts entry (if
> it
> exists); but do not add a new entry.
>
> The pendingRegistration list concept is to prevent massive
> registration traffic
> when supernode relay is in force. Regular REGISTER attempts will
> still occur;
> but not for every received packet.
>
ok
> A peer is only considered operational for peer-to-peer sending when a
> REGISTER_ACK is returned. Once operational the peer is kept
> operational while
> any direct packet communications are occurring. REGISTER is not
> required to
> keep the path open through any firewalls; just some activity in one
> direction.
I believe that some activity is necessary and if not then a REGISTER
can be used for keeping the firewall port open
>
> After an idle period; the peer should be deleted from the
> known_hosts list. We
> should not try to re-register when this time expires. If there is no
> data to
> send then forget the peer. This helps scalability.
ok agree
>
>
> If a peer wants to be remembered it can send gratuitous ARP traffic
> which will
> keep its entry in the known_hosts list of any peers which already
> have the
> entry.
Ok, perhaps the arp flush timeout can be used also as time for
deciding when to delete a peer from cache
>
>
>
> In pseudo C
>
>
> peer = find_by_src_mac( hdr ); /* return NULL or known_hosts entry */
>
> if ( NULL != peer )
> {
> peer->last_seen = time(NULL);
> }
> else
> {
> /* peer not currently in known_hosts */
> if ( ! is_broadcast( hdr ) ) /* ignore broadcasts */
> {
> if ( is_REGISTER_ACK( hdr ) )
> {
> /* move from pending to known_hosts */
> set_peer_operational( hdr );
> }
> else
> {
> /* add to pending and send REGISTER - ignore if in
> pending. */
> try_register( hdr )
> }
> }
> }
>
>
> --- Luca Deri <[EMAIL PROTECTED]> wrote:
>> Richard
>> the register time is used to keep track of the latest reception of a
>> register-ack that indicates that an edge node can be reached
>> directly.
>>
>> Hence the time has to be set only when a register ack is received. In
>> fact if you do set the time even when the register request is sent,
>> the edge node believes that it can reach a node directly. And this is
>> wrong unless a ack has been received.
>>
>> Is it clear now?
>
>
>
>
> Get the name you always wanted with the new y7mail email address.
> www.yahoo7.com.au/y7mail
>
_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev
