This could just be someone giving good advice especially if the downloader was using or had experience with WinMx 3.00 as there is an issue with this over compatibility protocol wise with AudioGnome, Macnap and Lopster, to quote three different platform client.
Using Auto-retry produces some really unreliable resultsas does trying the join the queue to a "Queueable" responce.
Each time you use this feature you are returned to the server to negotiate again the connection, all to often the next response is timed out, it seems to get a response from the distant end in as much as the BUSY QUEUABLE response returns but you never get actually connected into the distant queue.
Sorry if this is not very clear but my idea of what is happening is in itself not clear, all I have discovered is that once you get busy queueable if you set auto-retry and leave it, provided the server is still there when your turn comes around you will eventually get the waiting for incoming conection and with luck an eventual connection.
I feel the protocol is wrong hereand that both OpenNap and SlavaNap have gone so far away from the sensible standards laid down in the original specification, that performance and user friendlyness are being rapidly eroded.
It will not be the RIAA or your ISP that destroy P2P but the users themselves giving up in disgust at the frustration of seeing all the goodies and not being able sensibly to get them .
My proposals outline a change of protocol where once a busy queue status is established the temporary connection to the distant user should be retained for a period to allow an automated "join queue" response to take place, how this will be achgeived I have as yet no idea, but it must be the way forward if P2P and OPennap are to survive, or it will be all WPNP/ WNP and Fastrack/Sharman networks only keeping users online.
Snark.
