-
To generate one or several SN lists for various countries, start by opening KaZuperNodes from your Kazaa Lite "Tools" menu. Run the following process using KZN (short for KaZuperNodes). Repeat this process on different SuperNode connection lists until you are satisfied with its results or you are exhausted, which ever occurs first. It can start from any connected Node, even if that node is just a Client rather than a SuperNode.
Here's how to run the process:
First verify the current status of all listed node candidates by clicking the button next to the list form showing a "lightning strike" icon. Until the current status checking process is finished, all the other buttons will be changed to a gray "unavailable for use" appearance. Be patient. When processing is done, they will change back to their higher contrast "available for use" appearance. Then update and correct currently reported country address tags by clicking on the next button showing a "flash light" icon. I have often seen country tags for specific new listings change during country address updates. The buttons will "gray out" again because this is another processing activity. Next, sort this list first by Status, then by Country. Perform these sorts by clicking on the words "Status" then "Country" at the top of the form's column headings. Sorting all candidates into groups by country and status is really fast and saves time. SuperNodes are shown as an S on a green circle. Connected Clients are shown as a C on a yellow circle. Unconnected Clients are shown as a ? on a red circle. Next, use this displayed information to select which of these you want to add to your SuperList by highlighting that group. The fastest way to highlight any desired sorted group is to first left-click on either the top or bottom listed IP, then while holding down either shift key, left-click on the other (top or bottom) group IP. This is faster than holding down the Control key while left-clicking on every candidate in a long list. Next right click on any highlighted listing to reveal a menu from which you select "Add highlighted entries to SuperList." Don't worry that some of these listings may already appear in your SuperList because KaZuperNodes is smart enough to limit listings to one entry for each IP address. If you still want more new listings, repeat this process after connecting to another node. I think capturing SuperNode connection lists is better than starting with randomly selected Connected Clients, but I'm not sure if that's true. Perhaps FTFakes who wrote KZN will comment.
Here's how to connect to a new SuperNode. Decide on a list candidate you like based on location, connect speed, name preference, numerology, or what ever appeals to you. If a SuperNode operator names their node "FBI" I don't necessarily believe it's an FBI operation, but I'm unlikely to go out of my way to connect my P2P software to it. You make your own decisions. Then left-double-click on that candidate listing which will copy its address into the KZN lower right side address box. Just above that address box is another button showing the same "lightning strike" icon. Left-click on that button to reconfirm its current status. If it comes back reconfirming SuperNode status, click on the next button to the left to attempt connecting to that as a new SuperNode. Sometimes connecting requires several attempts. If it won't connect, try another candidate. When a new SuperList is connected, you will see its connections appear in the form list on the left. Now you're ready to start all over again. Each time you run it, you'll usually capture new SuperNodes which is how lists are built. Keep changing to new SuperNodes and capturing each one's SuperNode contact list, sort, screen, select and save to SuperList until you get as many newly verified SuperNode IPs as you want or your patience allows. When you have a nice long list of future candidates, for crying in the beer SAVE IT! I save both Favorites (saved in *.kzf format) and the new SuperList (saved in *.kzn format).
Many descriptions contain assumptions which prevent some readers from following what's being explained. I wrote this in an attempt to allow as many readers as possible to track the explanation. I apologize to those who feel this approach explained steps they thought too obvious to merit explanation. But never before has the need for preserving useable SuperNode contact lists been greater. Any contained errors are my fault, whereas the real credit for making this possible is owing to FTFakes.
Tenor Singer
-
Continuing education, not for experts because they already know this.
Connected Clients are systems running Peer to Peer exchange software. SuperNodes are also Clients. But SuperNodes are also enabled to connect many other clients together with a file description query and response routine that enables direct connections between participants when Q&A matches occur. Only file descriptions rather than actual file data pass through SuperNodes when they perform this match making act. When the SuperNode software feature kicks into operation, the system operator is probably not aware that it has started, so they usually don't know that they have become a SuperNode. The CPU load on their system is reportedly quite low.
When considering connection response speeds, you should consider two speed estimates. One is how fast your system connects to each SuperNode on your list. KaZuperNodes measures and reports those response speeds for us. But the response speed between your system as a Client and any SuperNode only directly affects search routine speeds. The more important speed estimate you should consider is, how fast are connections likely to be between your system and the average of all other clients connected to each considered SuperNode? KaZuperNodes can't provide this more important second speed estimate because it's not built into the FastTrack protocol. Why wasn't it built-in? Probably because there was no known way to simply and safely do it without compromising privacy. Consider this hypothetical example which will illustrate why P2P connect times couldn't be predicted. Two Chicago residents unknowingly connect to the same Australian SuperNode with identical Client to SuperNode response times of 5. If that SuperNode arranges for an exchange between them, there is no way for it to guess whether the new Client to Client response time will be 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 or 10. The worst expected case should be 10, but in this case their actual Client to Client response time is 0. But we can't know that ahead of testing the connection. This second speed estimate applies to actual file transfers, because as soon as you start transferring any files, your transfers occur directly from Client to Client, not from Client to SuperNode to Client. So this second speed (Client to Client P2P) can't be known nor reliably predicted. But typically connections within any country are faster than between participants in different countries. US residents near the Canadian border may get connections 5 times as fast to some Canadian sites than to Los Angeles. So Country tags are a helpful but not ideal transfer speed predictor. If all FastTrack participants followed the advice of connecting to the closest and lowest measured response time SuperNodes from their view, clumping donors together with receivers would occur powerfully minimizing response times, a desirable tendency. If minimizing response times were the only goal, that would be ideal. But it's not the only goal.
Country tags are the best predictor of what files are likely to be available on specific SuperNodes. Why? Because tastes in file content display powerful regional patterns. Italian singers are even more popular in Italy than in other countries. Lectures in german are more popular in Germany than in other countries. Sexy Japanese drawings are even more popular in Japan than in other countries. Hundreds of correct comparable statements can be made. So if you want to collect works by artists in a remote region, it generally works to your advantage to connect with SuperNodes from regions where those files are most popular. This truth provides a vexing problem and oddly, with KaZuperNodes, it also provides a solution to that very problem: how can we locate SuperNodes in remote regions? This involves running searches which are likely to bias successful Client/SuperNode matching locations to occur from our region of interest. Then using KaZuperNodes to identify respondents' countries of origin, and capture SuperNodes they use to our lists for future inquiries. This approach is based on the assumption that past behavior is an excellent predictor of future behavior. But that expanded explanation will have to wait for another installment. Hope considering these issues is proving interesting to a few readers.
Tenor Singer
