OK - I'll make a start.
--- Luca Deri <[EMAIL PROTECTED]> wrote:
> 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
> >
>
>
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
