* An important note about those who use BearShare is to connect to the network at least a couple times a month so your connection list stays up-to-date. I have noticed that 90-95% of the BearShare host addresses change over a 2 month period.

There are 'flash in the pan' users who try BearShare out for the first time but do not return. There are some who are casual users. And of course, there are dynamic hosts who change their address, some frequently. And there might also be some who only occasionally connect as Peers but connect generally as Leafs.

As for my experiment to attempt to create a connection list concentrating on static hosts, it is a little too difficult since there does not appear to be enough static bearshare hosts out there that connect as Peers and are consistent users of BearShare. I will keep trying for the time being. The idea of my list is to help those get connected for the first time or if they have not used BearShare for some time and are having connection problems (ie: connection list out-of-date.)

And as mentioned in my previous post, the longer you stay connected to the network per session, the better you will be seen as a good host to connect to. BearShare records the amount of time each user stays connected to the network and the GWebCache host sites will keep a rating system for the most reliable hosts to connect to, transferring the time they have spent online etc. If a user has not been online in over a week then their rating might go down.
Edit 5 March 2014: the above rating system only applies if you are not firewalled. BearShare will not cache the connection details of BearShare 5.1 Beta users who are firewalled. I've been manually adding such hosts to the connection file to keep the list as up to date as possible, even if that means firewalled ultrapeers, which is not good for the network. But keeping them listed below the non-firewalled ultrapeers. Obviously the BearShare ultrapeer population is not very large.

Peerless commented to me that if you cannot connect to BearShare hosts first time, restart BearShare and (hopefully) you will find them easier to find and connect to.

i can vouch for what Peerless says about restarting bearshare and the computer. the only issue that still remains a problem for me is the date change.

The date-change is something File_Girl71 would need to fix. I know it can be slow to change back for some people and maybe not change back at all. It may take some minutes. It is only supposed to take 10 seconds or so. It might depend on a particular person's system set-up.

Quote:

Originally Posted by Lord of the Rings (Post 367989) The date-change is something File_Girl71 would need to fix. I know it can be slow to change back for some people and maybe not change back at all. It may take some minutes. It is only supposed to take 10 seconds or so. It may depend on a particular person's system set-up.

i did find this: Make Windows synchronize time more often . but it only works for the time and not date.
Anyone know if a program that syncs the date?

GWebCache sites
 

I checked 36 GWC's and out of those some were dead, some still active, some unsure (these sites might not be configured for standard human contact.) Out of the unsure gwc's, 4 had websites but no indication of hosting and perhaps even totally unrelated topic websites (possibility of the domain being sold).

14 Dead
11 Unsure
11 Still active

I am still convinced at least one still active GWC (if I can call it active) is giving out-of-date information. Two of my BearShare connection lists (Win 8 + 2000) contain many hosts at top of the list from January but mostly from December and earlier (nearing a year old). One of my BS work lists is colour coded so a quick look to see when they were last seen (or a specific search for last exact date seen.) The Windows 8 list I started from scratch with just a dozen (or less) of active BS hosts a month or two ago. I was interested to see how it built up the list on its own.

Of course I have considered that I might simply not have seen such hosts and perhaps some of these hosts might still be active. However, I have major doubts that is the entire reason. The portion of the BS community that runs as peers does not seem to be dramatically large.
And then there's the occasional one I spot via another program that had not been seen before.

I do not like the way BS caches hosts locally. I have mentioned this before. And I suspect this contributes to the BS connection list going out of date fairly quickly. As examples, I can be connected to a host I've seen several times over a week or two but they are not to be found on the connection list. I can be connected to a host for a day or two, and they are not cached locally. I can be connected to a host who has an uptime of 6 days and they are also not to be found. I find myself manually adding hosts to the connection list. sighs
I also see decent reliable hosts rated lowly.
Perhaps this behaviour was limited to the BS 5.1 version, I don't know. But when the host list is only half-full and BS does not consider adding hosts for some unknown reason, it leaves me wondering and in no doubt why BS cache goes out of date fairly quickly.
The only logical reason I can think of why BS does not cache a host that has an uptime of 2-3 weeks and I've been connected to them for a few days is they are TCP firewalled. And thus not considered a worthy addition. This might happen if using BS 5.1 or earlier and not port forwarded which is a necessity. I doubt it is only a UDP firewalling issue as BS's UDP tests appear to fail rather frequently. ie: I've read whilst UDP is more bandwidth friendly, it is also known such UDP messages can get lost in transit rather easily. Not surprising when you consider the hammering hostile hosts give BS.
Edit 5 March 2014: Firewalled ultrapeers are not added/cached to the connection file. This is one reason many BS peers are not added to the connection file by BearShare itself. Those using BS 5.1 Beta must port forward the port they are using for both TCP & UDP or else, they will be firewalled. Other BearShare versions would simply not allow the program to become an ultrapeer if it were firewalled.

Auto Host 86.2x8.1x3.126:18335 ("gtk-gnutella/1.0.1 (2013-12-31; GTK2; Linux x86_64)") dropped: response code: 403 'Not a network member'. That's how GTK-Gnutella peers respond to firewalled BearShare 5.1 Beta ultrapeers! Handshake connection failed, communication between dropped.

I'd be curious to know where BS gets its local caching information from, other peers or gwc. ??? :confused:
(It would not surprise me if the 5.2+ versions were deliberately designed to pass out bad connection caching data. Whatever the causes are, it is definitely a problem.)


Edit: 20 June 2013:

Host in x.x.x.x ("GNUCRAWL (crawl)") Replied to crawler.
-- Handshake 1 IN --
GNUTELLA CONNECT/0.6\r\n
User-Agent: GNUCRAWL (crawl)\r\n
X-Ultrapeer: False\r\n
Query-Routing: 0.1\r\n
Crawler: 0.1\r\n
\r\n

-- Handshake 2 OUT --
GNUTELLA/0.6 503 Full\r\n
User-Agent: BearShare 5.1.0b25\r\n
Peers: xx.x.x.x:6346,xxx.x.x.x:6348,…,...,.. etc.

So BS does communicate with such crawlers after all. (I was using Win 8 at the time, not one of its happiest days re: FW indication for UDP. BS had crashed before a reboot.)
It listed the peers then leafs I was connected to. Then 5 suggestive peers to try. One of these was a specific USA host address listed (not a range) on the Hostiles list. Hoorah. lol ... 20% failure rate. At least not as bad as GWC which tend to be saturated with hostile hosts. Some GWC's I've seen are really bad for such hosts. But as might have crossed your mind, the other 4 hosts suggested might have been proxy addresses, ie: possibility of a hostile crawler giving out bad data. The crawler itself was using a dynamic 24.x.x.x ip range. . (FYI all the 5 hosts used standard ports 6346 x2, 6348 x3. Germany, Poland, Belgium, USA x2)

Crawlers should be set up with both ip and port filters so they can be trusted.

Proxy addresses make it difficult. But I've had an idea for a long time, just wish I could program. :D They can be detected with the right tools and I've already posted such evidence on the forum quite some time ago where a proxy (hostile host) user was clearly shown with both their addresses. This is different to the standard gnutella protocol check for false/fake host addresses.

Volunteers wanted for updating BearShare connection file
 

With a BearShare ultrapeer population of only about 20, I find it a little pointless continuing with the updated connection installers. To my knowledge, BearShare reserves 18 connection slots for BearShare peers out of a total of 26. I doubt I've ever connected to more than 15 BearShare peers at any time.

About 3/4 the peer population have dynamic addresses. And over half the peer population use the BS 5.1 Beta & are firewalled because they're too lazy to port forward their routers (BS 5.1 beta 'requires' port-forwarding.) A TCP firewalled ultrapeer is very damaging to the network. Because the BearShare peer population is so small, I feel obligated to include these firewalled peers on the connection file despite no other program including BearShare does this.

I spend much of my time arranging the non-BearShare connection hosts. But this seems almost totally irrelevant because BearShare concentrates upon finding hosts via GWeb sites. Hosts from the connection file are given very low priority.
As for the BearShare hosts on the connection list, many stay there in hope they might return 'lol'. Because otherwise the host size would only be about 20 hosts.

It's not only the very small & always changing BearShare peer population that's disappointing, but probably much more-so all those hosts who are firewalled ultrapeers. That just makes me feel ill and want to walk away. "!" "."

I realise the connection list is not only for ultrapeers, but also for leafs.

There seems no lack of BearShare leafs, in fact I've spent many a long session (4+ days) trying to help out catering for their needs to connect to at least some BearShare ultrapeers. BearShare's 38 reserved leaf slots for BearShare leafs out of 45 are always filled rather quickly whether I run one or even four BearShares. BearShare v.4 apparently would only connect to other BearShare hosts. There just isn't enough BearShare ultrapeers now, nor is there enough good ones who are not firewalled & blocking everyone's search messages.

Time for me to move on. Perhaps someone else might volunteer a connection list periodically if you care for their community. ;)

(I have a very high respect for those BearShare ultrapeers who are relatively long timers & are not firewalled. I love your dedication!)

Connection installer now packaged with gwebcache file. How to port forward
 

The connection installer is now packaged with a gwebcache file set to Read Only. BS has a built-in default list of almost 40 GWCs where most no longer exist and the few that do are not compatible with BS's out-of-date GWC request approach. Whilst BS might still occasionally dig into its default internal list, this is still better than total failure. Upon testing no errors were recorded either in BS console or program functioning on Win 8, XP or 2k.

Some people are unaware that the BS 5.1 Beta is not a simple plug-in & run program, but instead it requires port forwarding your modem-router before general use. This is not an if or but, it is a MUST do scenario. Firewalled ultrapeers do considerable damage to the network. But this is so easily fixed by port forwarding.

Port forwarding is not some complex scientific mathematical formula! In most cases it is actually quite easy and you will realise this after you have done it.

Whilst Port forwarding is a must for BS 5.1 Beta, it is also beneficial for those running any other version of BearShare. BS's UPnP adopted in later versions does not work for everyone. After port forwarding you will notice the dramatic difference and improvement in BS's performance.

Port Forwarding steps:

1. Set up a Static internal ip address (no this is not your external ip address.) The internal address is what your computer uses when communicating with the router and other computers on the same network (such as your partner or children's computers.) Internal addresses might be something like 192.168.1.2, 192.168.1.3, etc. or 10.1.1.2 where the modem-router's address would be the first in line, example: 192.168.1.1 or 10.1.1.1
Guide on setting up a static internal address:
How to Setup a Static IP Address in XP, Vista, Windows 7, and Game Consoles

2. Forward a port.
The default port to use for gnutella is port 6346 (or 6348), however the BS 5.1 Beta we link to on the forum has its port set to 6348 which would be the easiest for you to use.
Using another port? Some ISP's that filter file-sharing content might monitor or filter these ports. A safer port range to use would be anywhere between a five number port of 20000 and 60000. Examples are ports 23835 or 37140 or 53192, etc.
If you should choose a different port, you will also need to make adjustments within BearShare's settings. ie: BearShare's menu bar, Setup, Connection, and change the port number in the box at bottom of that window to match the one you used for port forwarding. A restart of BS would be required.

Port Forward guide:
Router Port Forwarding Guides
(1) Choose the brand of modem-router you use (click close to the advertisement top-right of screen.) (2) Then choose the model of modem-router you use. (3) Then choose the program you are port forwarding for. Obviously BearShare in this case under the B menu portion so scroll down to that part. Now you can follow the instructions with the variations I have suggested earlier about which port to use.

In regards to setting up a static ip address, if you do not do this before the port forwarding process then the port forward rule will be designated to a particular internal address that rarely matches your computer in future. Here's an example of someone who forgot to set up a static ip address http://www.gnutellaforums.com/host-c...tml#post373809 and just recently saw them non-firewalled again 18 months later (that's how long it took.)

I am presently connected to 10 BearShare ultrapeers and 17 BS leafs. Out of the 10 BS ultrapeers only 3 are not firewalled. This simply should not even be allowed to happen. Please try to not be one of the damaging firewalled ultrapeers. How to know if you are not firewalled? Check the Light-like icon top-right of BearShare & it should be green, not yellow or red. If you are an ultrapeer then you should be connected to 3 or more BS leafs and a total of 11 or more leafs. (If an ultrapeer & connected to less than 3 leafs after an hour, you are firewalled!)

Do not forget to set BS to be allowed through your software firewall.

Hostiles: I removed the full-Japanese hostiles from the hostiles installer because the majority of BearShare users need as many hosts as they can to try to connect to. Japan represents one of the very best countries for the best of hosts to connect to. I am still hosting this particular hostiles but not at mediafire. If you are an experienced BS user and insist on the full block then you can find it at 4Shared (need to be registered at & logged into 4Shared to download the designated file.)

BS host-file bugs: I know I've commented about the BS host caching system before. But just to show how poor it is, two BS ultrapeers: one with uptime of 14 days and other with consistent uptime of 24 to 48 hours consecutively, have average uptimes of 38 mins and 80 mins respectively. Resulting in the best BS hosts at the bottom of the host-file. Obviously a severe bug with BS's host-file management.
There's other bugs also, such as multiple host listings, disregard of the hostiles when adding hosts to the host-file, and adding BS ultrapeers also to the non-BS list. The host-file also seems to obtain out-of-date host data with BS ultrapeers that have not existed for years (this might be due to a rogue BS ultrapeer.)