Igor:
Hello! I wanted to deliver the latest bug report
about Kaboodle before you got too far along in the "access
list" work. The second one relate directly to a piece you've
worked on:
1. During startup, Kaboodle tries a reverse-DNS of the devices
it discovers. Similar to a getHostName() lookup in *nix,
this request blocks until completion. For a NAT'd LAN like
mine with no DNS entries, this block lasts for 30 seconds
per device. After the reverse-DNS times out, Kaboodle tries
a NetBIOS lookup. After this is complete for all devices,
it begins looking for VNC servers. Moreover...it doesn't
stop trying to do a reverse lookup: Kaboodle is continuously
sending out reverse-DNS requests for device's it has
discovered. Once a request times out for one device, it
starts asking about another device.
We need to fix this so that the reverse-DNS doesn't block the
initial LAN discovery thread. We could either: (1) eliminate
it completely, and use only NetBIOS requests for device names
or (2) use DNS only if it works for a "test device". So,
Kaboodle would try a reverse-DNS of the machine it's running
on, and if that succeeds it would do this for the other devices,
else it would not. I'd prefer the second approach. Also, there's
no reason the process should be continuously ongoing.
2. Once all devices on the LAN have their DNS requests timed
out, the VNC server scan begins. I'm counting 4 packets per
device per port right now. So, for example, the machine that's
running Kaboodle sends 4 packets to 192.168.123.1:5900, spaced
out over 2 seconds. AFAIK, only one packet is really needed.
For my LAN with 5 devices, 4 packets each over 2 seconds, it
takes several minutes before VNC server discovery completes.
Thanks! I hope you enjoy the holiday with your family.
-Scott
_______________________________________________
Kaboodle-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kaboodle-devel
