Forgive me if this is an easy answer but I am a newbie to ShareazaPlus and P2P clients. I am running into download completion problems because I have a number of Downloads queued but the Network/ShareazaPlus is not completing the Downloads prior to the Sources drying up and going offline. I have several posts with over 90% download complete and still showing at least 1 Source(in fact several with 2 or more). Their Status is Active. I have tried "Scan For More Sources" to see if I could influence reconsideration of the current downloads getting time/resources however this does not seem to work. It appears that these decisions are controlled by the server. I have seen and partially attempted to Pause All posts with the exceptions of the ones I want to force complete but this did not seem to take immediate effect so I gave up on that approach. Can anyone fill me in on a solution to this problem? This is very non-productive to have invested all the way up to 99.9% complete and then lose the last remaining source to complete the file.
Thanks in advance.
Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Gene Soo,
Unfortunately, your problem is a common one. Sources (such as yourself if you are sharing files) come and go on peer to peer networks as you know. ShareazaPlus will hold on to the source if they go offline, and retry them periodically. If the source fails after a certain number of tries, it will be dropped. ShareazaPlus will look for new sources periodically as well, but the search it performs is limited, as to not burden the network greatly. With a rare file, it is sometimes a good idea to search for it yourself on the network. The most efficient way to do this is to search for the file with a unique identifier of it, its "hash".
To search for the file by its hash, you must fist copy the hash for the file (right click on the file, go to "Advanced" then select "Advanced Edit". A window will open and you will see a "Hashes" tab at the top. Copy the text after "SHA1:", then open a new search window. You will see a box that says "Type URN here for hash search" under the top search box. You will see a small blue "H" after the box, click that and select "SHA1:" this will enter "urn:sha1:[SHA1]" into the box enter the hash you copied after "urn:sha1:" and search. This search will span a greater portion of the network than ShareazaPlus's built in search.
Another important factor essential to good performance out of ShareazaPlus is an unimpeded connection. If ShareazaPlus is behind a firewall, it will not be able to communicate properly with the network, this will drastically reduce performance. At the bottom of the ShareazaPlus is a Firewall indicator for TCP and UDP packets. After being connected for awhile you should see "No Problem" after both. If you see "Firewalled" after either of them, you have a communication problem with the network/sources, and one drawback of many is you will not be able to download from sources that are also firewalled. If you have a router or other firewall, it needs to be configured. www.portforward.com is a great resource for step by step directions to configuring your router or firewall.
If you have any other questions post back.
Datz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Datz, Thanks for the explanation, it is very informative. To address your last comment about the firewall indicators, I do show that UDP is Firewalled and TCP is not("No Problem"). I will need to research my router/DSL Modem Firewall settings to see if I can influence this indicator.
I did have another question concerning the original subject of this post. Given the situation that I have established a queue of download requests that exceeds concurrent downloads(I am observing 9 by sorting on the Speed column), is it the P2P client(i.e. Shareaza Plus) that decides which requests to spend time on or does the Server make the decision and just feed the Client what it can get? If it is the latter that the Server is dictating, Could the UDP Firewalled situation directly effect the reason that I am seeing a lot of 90+% download completes with Multiple Client Sources being available but the Client is spending time on Download requests with much lower %Complete? I was hoping but am not witnessing FIFO processing of the requests I entered.
Thanks
Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Gene,
ShareazaPlus will prioritize downloads at the top of the list, in other words, it will try to contact the sources for the files at the top of the list first. The sources either upload to you, time out, or queue up to download to you. So the client will use what it can find through a search which can take some time. (You can see it "crawling" or searching through a number of Hubs, or "servers" in the search window. (left bottom)
Today, most p2p networks are decentralized, this means that there are no "central servers" that have a static address. The servers for the "Gnutella2" network are composed of clients such as ShareazaPlus. ShareazaPlus will go into "Hub Mode" when it decides the conditions are necessary to add additional servers to the network.(It is possible to disable the action)
Being firewalled severely limits who you can download from. Since Firewall to Firewall transfers are not possible at this point, if 50% of the network is firewalled, you may have just lost half of your sources. Port forward your router and you should see a sizable increase in performance.
Datz
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was able to solve the UDP Firewall issue. I found the configuration page in my Soft Firewall(TrendMicro Internet Security). I was able to get UDP to show as No Problem but now TCP shows as Unknown instead of No Problem. I could not get any good results from Connection Test under Help. Am I now impacted by the TCP indicator showing Unknown instead of No Problem?
Thanks
Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
So by no good results from the connection test I assume that it indicated that you were still firewalled? Did you put in the right port number that shareazaplus is using for the connection test?
If you have a router and have not configured it, you would most likely still be firewalled. Did you give the portforward site a shot?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There seems to be some firewalls which can not open same port on both TCP and UDP. on the other hand, some firewall can do it easily just have two item in firewall(one for TCP and the other for UDP), and then there seems to be some firewall which you need to specify something like "Both TCP and UDP" or "All Protocol" for one port to allow both TCP and UDP on same port number.
anyway, TCP and UDP are basically used differently, TCP are for transfering and for browsing and chatting. this will impact download performance if file you are looking for have a lot of Firewalled Sources, which are marked as "(PUSH)" in download source list, although some of them marked as "(PUSH)" can be not firewalled source, anyway, so basically if you and your source are both TCP firewalled, you basically can not download or upload file with him/her.
UDP, however, are used for searching file/source over G2 and ED2K network. if your shareazaplus is just behind NAT, then not much problem, but if it is firewall, not sure what gonna happen. there can be two types of firewalling for UDP. one is partial blocking which the firewall allow you to send packet, and allow you to receive responce from the one you sent packet to. however blocking packets if you have not sent packet to the originator, or even if you have sent packet to the host in past, there are some timeout and if the time comes, firewall forget about it. in this situation, it is OK on serching ED2K servers. for G2, it is little limited and you might have some performance loss on search, but not as severe as the one next. the other one is total blocking, which will not allow you to send and receive packets at all. if this is the one happening on you, you basically can not search over G2 at all because G2 search mainly use UDP because of its specification, just you can search your Hubs in Neighbour list and its leaves. ED2K is same for searches, if you can not use UDP, then you can search on your connected server, but can not search other servers using UDP.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the long delay between posts. I was able to figure out eventually how to configure my router to open the Ports and get Connection Test to work successfully for TCP and UDP. Now both report "No Problem". However, This status does not remain that way. Over a period of time, I will lose one of the settings to "Unknown" or "Firewalled". Also, the only way I can get this status to be reevaluated is by running the Connection Test dialog. It is annoying running this dialog over and over again to maintain maximum throughput. Is Shareaza Plus supposed to perform this test on it's own or was it designed to be exclusively manual?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, ShareazaPlus has some implementation to reset Firewall status periodically. how it is doing is totally different to Shareaza.
Shareaza check Firewall status only once and once it has proven to be not firewalled, then it remains not firewalled forever. this can be some problem that there may be some situation that FW status may be wrong because under certain condition, specially UDP, FW detection does detect it as not firewalled when it is firewalled.
ShareazaPlus, check Firewall status once at connecting time, but there are status back log for 1hour. status are updated once per 5minute depending on incomming connections and packet. which means if your shareazaplus is working busy then you will get status "not firewalled" (Uploading are for TCP. Downloading (PUSH) sourrce are TCP. search result for G2 for UDP. some ED2K uploading are for UDP). unfortunatelly not all network has way to detect the firewall status (actually it is better to say i do not know how to find it for G1 and BT at all) so if you do not have G2 connected, then you may have some situation that your status keeps changing in between "unknown" and "firewalled".
12 backlog are there for both TCP and UDP, and once the half of the log(30minute) saying firewalled, then start checking FW status again if possible. when it is in Checking state,
- (TCP)ShareazaPlus will try connect downloading file in different way for G2 sources, try using PUSH downloading method before doing normal download for non-firewalled sources to check if your TCP port is opened or not.
- (TCP)Send some PUSH packet to G2 neighbours to let it connect to you for checking (newly connected connection will check only and then disconnect)
- (UDP) send relay ping packet to G2 neighbours to let your Neighbours' neighbour to send UDP packet to you for Firewall detection.
for UDP Firewall connection there is some problem that if you have sent UDP packet to a host, then you can receive UDP from the host for a while until the packet in-between stop going and comming for a period. so shareazaplus has some check if you have sent UDP packet to the host or not within certain period or not. this can cause some other problem that if your neighbour has routed relay-ping packet to the hosts you have sent packet to within certain period, then the FW detection just fails.
so, unfortunately right now in order to keep status, you need to make it busy all the time.
P.S. if you have any idea or information, please post.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgive my end user ignorance but the most I got out of this last response was that Shareaza checked the Firewall status once and kept that status for the duration of the session. From my perspective, I wish Shareaza Plus did the same because I am getting weary fighting this program to keep it running at optimal speed. I am not sure for the technical reasons for rechecking the status peridocally and switching to statuses that would impact the performance. If this is a requirement of the P2P protocols then I would suggest that you add in a User controlled option for S+ to peridocally redrive the Connection Test function supplying the Port and Long timeout(Y/N) information requested by the panel. This is not the most efficient use of computer resources since the program logic will be fighting itself. One side is making checks that work toward reducing the download performance while my suggestion would be working toward the opposite goal. Unfortunately, I am forced to do this manually now and when I cannot redrive the check, I am running at the best speed for the degraded status. I wish you luck in sorting out the proper methodology for handling these issues. ... Thanks ... Gene
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
well, as i said, there can be some FALSEPOSITIVE for auto firewall detection, thats the reason why there are periodical check. you can disable periodical check in setting if you are sure it is not firewalled.
look in the settings there is some place saying "Accept Incomming connections". you set it to "YES" disable Firewall detection and making shareazaplus to think you are not firewalled at all.
> One side is making checks that work toward reducing the download performance while my suggestion would be working toward the opposite goal.
the FW check code on shareazaplus should not reduce Download performance a lot if you are not firewalled. there can be some exception but mostly not so much. the exception is if your download source has switched Neighbour Hubs from time you have found the source. Although Shareazaplus has some way to get latest HUB list of download source, it only works if the download source is ShareazaPlus (original shareaza parse the info in HTTP connection, only shareazaplus and some Shareaza modified versions do) so right now it may reduce performance for it. if you are uploading a lot.
if your upload is non-push connections, then TCP FW check will never invoked since it shows you are not firewalled.
for UDP, periodical Source search from your download file list should keep your UDP not firewalled state if you are not firewalled. although if you do no have a lot of download in download list, or all of your download have enough sources then this may not be invoked at all.
anyway, this periodical FW check is basically for noobs and users who does not have access to FW/Router configurations. there can be situation that port gets closed in runtime without the user knowing and so on. but if you are sure that your port is Open, then you can just force non-firewalled state in setting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Forgive me if this is an easy answer but I am a newbie to ShareazaPlus and P2P clients. I am running into download completion problems because I have a number of Downloads queued but the Network/ShareazaPlus is not completing the Downloads prior to the Sources drying up and going offline. I have several posts with over 90% download complete and still showing at least 1 Source(in fact several with 2 or more). Their Status is Active. I have tried "Scan For More Sources" to see if I could influence reconsideration of the current downloads getting time/resources however this does not seem to work. It appears that these decisions are controlled by the server. I have seen and partially attempted to Pause All posts with the exceptions of the ones I want to force complete but this did not seem to take immediate effect so I gave up on that approach. Can anyone fill me in on a solution to this problem? This is very non-productive to have invested all the way up to 99.9% complete and then lose the last remaining source to complete the file.
Thanks in advance.
Gene
Hi Gene Soo,
Unfortunately, your problem is a common one. Sources (such as yourself if you are sharing files) come and go on peer to peer networks as you know. ShareazaPlus will hold on to the source if they go offline, and retry them periodically. If the source fails after a certain number of tries, it will be dropped. ShareazaPlus will look for new sources periodically as well, but the search it performs is limited, as to not burden the network greatly. With a rare file, it is sometimes a good idea to search for it yourself on the network. The most efficient way to do this is to search for the file with a unique identifier of it, its "hash".
To search for the file by its hash, you must fist copy the hash for the file (right click on the file, go to "Advanced" then select "Advanced Edit". A window will open and you will see a "Hashes" tab at the top. Copy the text after "SHA1:", then open a new search window. You will see a box that says "Type URN here for hash search" under the top search box. You will see a small blue "H" after the box, click that and select "SHA1:" this will enter "urn:sha1:[SHA1]" into the box enter the hash you copied after "urn:sha1:" and search. This search will span a greater portion of the network than ShareazaPlus's built in search.
Another important factor essential to good performance out of ShareazaPlus is an unimpeded connection. If ShareazaPlus is behind a firewall, it will not be able to communicate properly with the network, this will drastically reduce performance. At the bottom of the ShareazaPlus is a Firewall indicator for TCP and UDP packets. After being connected for awhile you should see "No Problem" after both. If you see "Firewalled" after either of them, you have a communication problem with the network/sources, and one drawback of many is you will not be able to download from sources that are also firewalled. If you have a router or other firewall, it needs to be configured. www.portforward.com is a great resource for step by step directions to configuring your router or firewall.
If you have any other questions post back.
Datz
Datz, Thanks for the explanation, it is very informative. To address your last comment about the firewall indicators, I do show that UDP is Firewalled and TCP is not("No Problem"). I will need to research my router/DSL Modem Firewall settings to see if I can influence this indicator.
I did have another question concerning the original subject of this post. Given the situation that I have established a queue of download requests that exceeds concurrent downloads(I am observing 9 by sorting on the Speed column), is it the P2P client(i.e. Shareaza Plus) that decides which requests to spend time on or does the Server make the decision and just feed the Client what it can get? If it is the latter that the Server is dictating, Could the UDP Firewalled situation directly effect the reason that I am seeing a lot of 90+% download completes with Multiple Client Sources being available but the Client is spending time on Download requests with much lower %Complete? I was hoping but am not witnessing FIFO processing of the requests I entered.
Thanks
Gene
Gene,
ShareazaPlus will prioritize downloads at the top of the list, in other words, it will try to contact the sources for the files at the top of the list first. The sources either upload to you, time out, or queue up to download to you. So the client will use what it can find through a search which can take some time. (You can see it "crawling" or searching through a number of Hubs, or "servers" in the search window. (left bottom)
Today, most p2p networks are decentralized, this means that there are no "central servers" that have a static address. The servers for the "Gnutella2" network are composed of clients such as ShareazaPlus. ShareazaPlus will go into "Hub Mode" when it decides the conditions are necessary to add additional servers to the network.(It is possible to disable the action)
Being firewalled severely limits who you can download from. Since Firewall to Firewall transfers are not possible at this point, if 50% of the network is firewalled, you may have just lost half of your sources. Port forward your router and you should see a sizable increase in performance.
Datz
Datz,
I was able to solve the UDP Firewall issue. I found the configuration page in my Soft Firewall(TrendMicro Internet Security). I was able to get UDP to show as No Problem but now TCP shows as Unknown instead of No Problem. I could not get any good results from Connection Test under Help. Am I now impacted by the TCP indicator showing Unknown instead of No Problem?
Thanks
Gene
Hello,
So by no good results from the connection test I assume that it indicated that you were still firewalled? Did you put in the right port number that shareazaplus is using for the connection test?
If you have a router and have not configured it, you would most likely still be firewalled. Did you give the portforward site a shot?
Hello Gene Soo.
sorry about very late responce.
There seems to be some firewalls which can not open same port on both TCP and UDP. on the other hand, some firewall can do it easily just have two item in firewall(one for TCP and the other for UDP), and then there seems to be some firewall which you need to specify something like "Both TCP and UDP" or "All Protocol" for one port to allow both TCP and UDP on same port number.
anyway, TCP and UDP are basically used differently, TCP are for transfering and for browsing and chatting. this will impact download performance if file you are looking for have a lot of Firewalled Sources, which are marked as "(PUSH)" in download source list, although some of them marked as "(PUSH)" can be not firewalled source, anyway, so basically if you and your source are both TCP firewalled, you basically can not download or upload file with him/her.
UDP, however, are used for searching file/source over G2 and ED2K network. if your shareazaplus is just behind NAT, then not much problem, but if it is firewall, not sure what gonna happen. there can be two types of firewalling for UDP. one is partial blocking which the firewall allow you to send packet, and allow you to receive responce from the one you sent packet to. however blocking packets if you have not sent packet to the originator, or even if you have sent packet to the host in past, there are some timeout and if the time comes, firewall forget about it. in this situation, it is OK on serching ED2K servers. for G2, it is little limited and you might have some performance loss on search, but not as severe as the one next. the other one is total blocking, which will not allow you to send and receive packets at all. if this is the one happening on you, you basically can not search over G2 at all because G2 search mainly use UDP because of its specification, just you can search your Hubs in Neighbour list and its leaves. ED2K is same for searches, if you can not use UDP, then you can search on your connected server, but can not search other servers using UDP.
Sorry for the long delay between posts. I was able to figure out eventually how to configure my router to open the Ports and get Connection Test to work successfully for TCP and UDP. Now both report "No Problem". However, This status does not remain that way. Over a period of time, I will lose one of the settings to "Unknown" or "Firewalled". Also, the only way I can get this status to be reevaluated is by running the Connection Test dialog. It is annoying running this dialog over and over again to maintain maximum throughput. Is Shareaza Plus supposed to perform this test on it's own or was it designed to be exclusively manual?
well, ShareazaPlus has some implementation to reset Firewall status periodically. how it is doing is totally different to Shareaza.
Shareaza check Firewall status only once and once it has proven to be not firewalled, then it remains not firewalled forever. this can be some problem that there may be some situation that FW status may be wrong because under certain condition, specially UDP, FW detection does detect it as not firewalled when it is firewalled.
ShareazaPlus, check Firewall status once at connecting time, but there are status back log for 1hour. status are updated once per 5minute depending on incomming connections and packet. which means if your shareazaplus is working busy then you will get status "not firewalled" (Uploading are for TCP. Downloading (PUSH) sourrce are TCP. search result for G2 for UDP. some ED2K uploading are for UDP). unfortunatelly not all network has way to detect the firewall status (actually it is better to say i do not know how to find it for G1 and BT at all) so if you do not have G2 connected, then you may have some situation that your status keeps changing in between "unknown" and "firewalled".
12 backlog are there for both TCP and UDP, and once the half of the log(30minute) saying firewalled, then start checking FW status again if possible. when it is in Checking state,
- (TCP)ShareazaPlus will try connect downloading file in different way for G2 sources, try using PUSH downloading method before doing normal download for non-firewalled sources to check if your TCP port is opened or not.
- (TCP)Send some PUSH packet to G2 neighbours to let it connect to you for checking (newly connected connection will check only and then disconnect)
- (UDP) send relay ping packet to G2 neighbours to let your Neighbours' neighbour to send UDP packet to you for Firewall detection.
for UDP Firewall connection there is some problem that if you have sent UDP packet to a host, then you can receive UDP from the host for a while until the packet in-between stop going and comming for a period. so shareazaplus has some check if you have sent UDP packet to the host or not within certain period or not. this can cause some other problem that if your neighbour has routed relay-ping packet to the hosts you have sent packet to within certain period, then the FW detection just fails.
so, unfortunately right now in order to keep status, you need to make it busy all the time.
P.S. if you have any idea or information, please post.
Forgive my end user ignorance but the most I got out of this last response was that Shareaza checked the Firewall status once and kept that status for the duration of the session. From my perspective, I wish Shareaza Plus did the same because I am getting weary fighting this program to keep it running at optimal speed. I am not sure for the technical reasons for rechecking the status peridocally and switching to statuses that would impact the performance. If this is a requirement of the P2P protocols then I would suggest that you add in a User controlled option for S+ to peridocally redrive the Connection Test function supplying the Port and Long timeout(Y/N) information requested by the panel. This is not the most efficient use of computer resources since the program logic will be fighting itself. One side is making checks that work toward reducing the download performance while my suggestion would be working toward the opposite goal. Unfortunately, I am forced to do this manually now and when I cannot redrive the check, I am running at the best speed for the degraded status. I wish you luck in sorting out the proper methodology for handling these issues. ... Thanks ... Gene
well, as i said, there can be some FALSEPOSITIVE for auto firewall detection, thats the reason why there are periodical check. you can disable periodical check in setting if you are sure it is not firewalled.
look in the settings there is some place saying "Accept Incomming connections". you set it to "YES" disable Firewall detection and making shareazaplus to think you are not firewalled at all.
> One side is making checks that work toward reducing the download performance while my suggestion would be working toward the opposite goal.
the FW check code on shareazaplus should not reduce Download performance a lot if you are not firewalled. there can be some exception but mostly not so much. the exception is if your download source has switched Neighbour Hubs from time you have found the source. Although Shareazaplus has some way to get latest HUB list of download source, it only works if the download source is ShareazaPlus (original shareaza parse the info in HTTP connection, only shareazaplus and some Shareaza modified versions do) so right now it may reduce performance for it. if you are uploading a lot.
if your upload is non-push connections, then TCP FW check will never invoked since it shows you are not firewalled.
for UDP, periodical Source search from your download file list should keep your UDP not firewalled state if you are not firewalled. although if you do no have a lot of download in download list, or all of your download have enough sources then this may not be invoked at all.
anyway, this periodical FW check is basically for noobs and users who does not have access to FW/Router configurations. there can be situation that port gets closed in runtime without the user knowing and so on. but if you are sure that your port is Open, then you can just force non-firewalled state in setting.