Hello Scott,
I have added my code to wincvs. It has new strategy implemetation.

Regards,
Varsha

----- Original Message -----
From: "Scott C. Best" <[EMAIL PROTECTED]>
To: "mailbox" <[EMAIL PROTECTED]>
Sent: Thursday, June 20, 2002 8:23 PM
Subject: Re: [Kaboodle-devel] Re: arp cache flush questions


> VK:
> Great! Looking forward to seeing it in action.
>
> -Scott
>
> On Thu, 20 Jun 2002, mailbox wrote:
>
> > Hello Scott,
> > I have managed the active/deactive state differentiation without the ARP
> > cache flush and implemented your new strategy. I am testing my code at
> > present. I will put the code in wincvs after I finish the testing.
> >
> > Regards,
> > Varsha.
> > ----- Original Message -----
> > From: "Scott C. Best" <[EMAIL PROTECTED]>
> > To: "mailbox" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Wednesday, June 19, 2002 9:40 PM
> > Subject: Re: [Kaboodle-devel] Re: arp cache flush questions
> >
> >
> > > VK:
> > > I don't see that it will slow down the discovery process.
> > > As it is now, everything gets discovered first, and then the OS
> > > detection begins (I can watch the packet traffic to see this).
> > > The GUI doesn't update until after the OS detection process is
> > > done for every device. So, in what's described below, the GUI
> > > will actually update quicker in some cases.
> > >
> > > You can add the ARP cache flush if you really want to
> > > for the 256 pings, but I don't see the point. It's unreliable and
> > > it doesn't add to the functionality.
> > >
> > > As far as "a lot of code rewrite", I think you will find
> > > it more "a lot of code reorganization". This process does the
> > > same thing as before, it just does it in a more structured order.
> > >
> > > Finally, please start using the CVS system again. It's
> > > difficult for me to evaluate your code if it's not intergrated
> > > with everyone else's. Even if this causes problems, it will help
> > > us to find those problems quicker.
> > >
> > > -Scott
> > >
> > >
> > > On Wed, 19 Jun 2002, mailbox wrote:
> > >
> > > > Hello Scott,
> > > >
> > > > This new strategy involves lot of code rewrite and may be slow down
in
> > the
> > > > discovery process. For new strategy I need to add the thread for the
OS
> > > > discovery. I had done that in  same thread.
> > > >
> > > > Can I just add the ARP cache flush just for the 256 pings?
> > > >
> > > > I have removed the ARP cache flush for active and inactive device
pings
> > and
> > > > added the 3 pings in 10seconds if the device fails to ping request
in
> > active
> > > > state.
> > > >
> > > > Regards,
> > > > Varsha.
> > > >
> > > > ----- Original Message -----
> > > > From: "Scott C. Best" <[EMAIL PROTECTED]>
> > > > To: "mailbox" <[EMAIL PROTECTED]>
> > > > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > > > Sent: Wednesday, June 19, 2002 11:56 AM
> > > > Subject: [Kaboodle-devel] Re: arp cache flush questions
> > > >
> > > >
> > > > > VK:
> > > > >
> > > > > > Scott can you please answer my following questions.
> > > > >
> > > > > No problem...
> > > > >
> > > > > >             Please: as per the spec, a device should transition
> > > > > > from active to inactive status when it fails to respond to
> > > > > > with an ICMP echo reply to three ICMP echo request (aka, pings)
> > > > > > in a row spaced over 5 seconds. Nothing else.
> > > > > >
> > > > > > The Old specification says 10seconds and above you are saying
> > 5seconds.
> > > > > >
> > > > > > Which one should I use?
> > > > >
> > > > > Ah, my mistake. 10 seconds is fine.
> > > > >
> > > > > >   1.. Startup: There will be arp cache clean up only on startup.
> > Right?
> > > > > >
> > > > > >   2.. Passive detection: When the Kaboodle detects the new
device in
> > > > > > passive detection process it starts active detection. (In active
> > > > > > detection process we send 256 pings and repeat the same above
> > > > > > procedure). In this case will there be ARP cache flush?
> > > > > >
> > > > > >   3.. Refresh: On refresh again we start the same active
detection.
> > In
> > > > > > this case will there be ARP cache flush?
> > > > >
> > > > > I think we can implement a strategy that doesn't require
> > > > > ARP cache flushing at all. It goes like this:
> > > > >
> > > > > 1. At startup, Kaboodle sends a ping to all 256 machines on the
> > subnet.
> > > > >    It sends a minimally sized ping packet, and it ignores the
replies.
> > > > >
> > > > > 2. Kaboodle then reads in the old Network Information Database
(NID)
> > > > >    from the registry if there is one. Call this LIST1. If there is
> > > > >    nothing in the registry, then Kaboodle is being run for the
first
> > > > >    time, and the user should be then shown a MessageBox which says
> > > > >    "Detecting Network...".
> > > > >
> > > > > 3. Kaboodle then reads in the ARP cache and puts it into LIST2.
> > > > >
> > > > > 4. Kaboodle then iterates thru LIST2 and deletes any device which
> > > > >    is already in LIST1.
> > > > >
> > > > > 5. Kaboodle then combines LIST1 and LIST2 to create LIST3.
> > > > >
> > > > > 6. Kaboodle then iterates thru LIST3, pinging each device to see
> > > > >    which are active and which are not. At the end of this process,
> > > > >    the "Detecting Network..." MessageBox can be removed.
> > > > >
> > > > > 7. When Kaboodle is done with LIST3 it then updates the GUI with
> > > > >    all devices in LIST3 which have already gone thru the OS
detection
> > > > >    process. Some devices will be shown with active ("On") icons,
> > > > >    and some with inactive ("Off") icons.
> > > > >
> > > > > 8. Kaboodle then iterates thru LIST3 again, this time looking for
> > > > >    *active* devices which have not yet gone thru the OS detection
> > > > >    process. If it finds one, it first displays a MessageBox saying
> > > > >    "Classifying New Devices...", and then it puts the new device
> > > > >    thru the OS detection thread, and then adds it to the GUI with
> > > > >    an active ("On") icon.
> > > > >
> > > > > 9. All remaining devices (ie, the inactive ones) in LIST3 are
> > > > >    discarded. The second MessageBox can now also be removed.
> > > > >
> > > > > When the sniffing thread discovers a new device, you should
> > > > > jump to step 3. When the Refresh button is hit, you should do all
> > > > > of the above steps (except in step #2...I forget if we serialize
> > > > > the NID into the registry all the time, or if it's in RAM).
> > > > >
> > > > > Sound good? Please note that in step-7, thew GUI is updated
> > > > > *before* new devices are put thru the OS detection thread.
> > > > >
> > > > > -Scott
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
> --------------------------------------------------------------------------
> > > > --
> > > > >                    Bringing you mounds of caffeinated joy
> > > > >                    >>>     http://thinkgeek.com/sf    <<<
> > > > >
> > > > > _______________________________________________
> > > > > Kaboodle-devel mailing list
> > > > > [EMAIL PROTECTED]
> > > > > https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>



-------------------------------------------------------
Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel

Reply via email to