Yesterday I decided to try Shareaza, so to make sure test results accurately reflected the software's capabilities, I precleaned the system downloading the latest virus definitions, then did the same with Ad-Aware, then with WebRoot SpySweeper, followed by a complete defrag. Clean, clean, clean, combed. During Shareaza's install it generated an instruction to configure my router/splitter to allow Shareaza full TCO access through Port 6346. But oddly the closing install screen offered to start Shareaza instantly despite the fact that no opportunity to reconfigure any router/splitter setup settings had occured yet! That's a stupid way to lead a parade. That closing screen should warn to only start the newly installed program if there is no hardware fire wall which must next be reconfigured with its setup program. So I let it run that way, as I expect most computer users would. This system is cable connected through an 8-port LinkSys router/splitter. I was surprised to discover that it actually worked at all! Further reading from other sites indicates that running Shareaza this way drastically reduces the number of P2P contacts with which the system can make exchanges. I gather that connections between parties, both of which are behind router firewalls, are impossible unless this "optional" (required to perform properly) port assignment is correctly changed through the user's router/splitter's setup program. The most robust P2P connect systems tend to be behind router hardware firewalls. So these common limp-along complaints claiming that Shareaza doesn't perform well for some people, yet has proven to perform very well for others, are almost certainly caused by these same complainer's personal user install errors. Sort of funny. KaZaa doesn't need an equivelant fire wall port assignment step. So previous experience with KaZaa doesn't warn Shareaza installers how important this final installation step for enabling full 2-way connection access. The Shareaza install routine is silly enough to invite people to try running it without allowing them a break to rerun their router's setup to assign TCP port access to Shareaza. So it should come as no surprise that these user complaints would be seen. Performance testing a new car with 4 flat tires could create a lot of complaints too, but that would display obvious user preconfiguration preparation failure had made proper testing impossible. Shareaza testing doesn't make this user preconfiguration prepartion failure obvious at all. I duplicated that probably common install without proper TCP 6346 port assignment for a 12 hour test. Lots of uploads occured from my system, but very few download request connections were made and completed. Improperly configured E-Mule by itself acts exactly the same way! So I strongly suggest to these complainers that they inflate their tires AND configure their ports before reporting performance complaints, which complaints are supposedly about the respective products rather than about their own preparation failures.
Just a friendly suggestion ~
Tenor Singer
