Following on from my side-topic here http://www.gnutellaforums.com/gtk-gn...ault-port.html (excluding 2nd half of post #1 & post #2.)

This host in question connects & browses at same time or simply only to browse. I did have this particular host banned & even on the hostiles for a short period of time. Since it is a 24/7 host, it seemed like a valuable UP on one hand. Yet on the other, it behaves like a suspicious BOT.

Should all GTK-Gnutella versions of 2007 builds not be trusted?

That's a very old version, but some people do like to use older versions of p2p clients. Though my understanding is that later GTK versions will black list them (or so I thought, but my GTK connected to a few of the 2007 builds.) But obviously other p2p clients don't blacklist them, which is why I ask my question, should it be trusted?
I am also aware some companies that use bots often use older version p2p clients.

Are you talking about hosts that advertise port 59345 and which run gtk-gnutella/0.96.4?

They seem to be running in a cloud, with many such instances around the world in different geographic locations. They do not have a huge uptime, meaning they are restarted quite frequently.

I do not know whether they are hostile, or just monitoring, or whatever. However, one thing is certain: this version is outdated and is harmful to the network due to the presence of routing bugs that were fixed much later.

Automatic browsing after connection suggests that the version was manually altered, since native GTKG does not have support for this auto-browse neighbors "feature"... To which purpose?

I connected to a new one recently for 1:23:58:46 (13-14 September) & 1d16h (15-16 September.) Similar ip to another in the 50.112. range & of course with port 59345 & an auto-browse host. If they're all using an Amazon Cloudf then of course their original ip could be anything.
gtk-gnutella/0.96.4-14059 (2007-07-07; Linux)
I don't know at this point if it's the same host with fresh ip or one I hadn't previously seen.

In what way is their presence damaging for connecting to the network?
Would I be advised to remove them from connection lists I offer via the forum?
They're so consistent I felt they would be helpful for connecting even if their motivation for being on the network is highly questionable.
If their ultrapeer status is damaging to the network, then should they be black listed?

I remember coming across hosts using Amazon over past couple of years that I had thoughts some might be bad in one way or another. I also suspected it was a dynamic ip system back then. (However the auto-browse GTK hosts appear to use static addresses.)

I noticed these older GTK hosts using port 59345 appear to all use Amazon Technologies as their ISP. One is a host apparently based in Japan, using Amazon Data Services Ireland. (Organization: Amazon AWS Services - Cloud' - LHR.)

BTW I wonder what would happen if Lime related clients included an option to disable being browsed. I guess that would almost spell the end to the concept of browse host. I wouldn't add it myself, except perhaps only for a personal customized version.
I get browsed so often & dislike the concept of their luck of the draw to find files to download they find by luck & choose without any real desire to have (of course a % of these are freeloaders.) Many of them are purely opportunists. And thus a lack of desire to share back to the network. I think Lime was the only main client not to offer the option to disable browse & since they represent the majority of the network. ~ One thought is if a host disallows being browsed, it disables their own ability to browse hosts. Otherwise it's somewhat of an unfair playing field.

Meanwhile I've been trying to look at how to fix the lime's brief upload queuing system. But this seems to be overridden in priority by a kind of greed defense system approach I've yet to find the answer to. And it needs to be fixed because it's buggy & results in unnecessary auto- preventing/cancelling of some uploads & temporary auto-blocking of hosts, even for modern clients like GTK, LPE, FW, etc. A bug that's probably existed since LW5 was borne.

On an even more off-topic: many experienced users would realise the so called LimeWire/4.21.1 (rc) is used for spamming the network. I discovered one of the most relable BearShare 5 hosts also seems to use LimeWire/4.21.1 (rc). Should this be a concern? I've seen lots of LimeWire/4.21.1 without the (rc), but the (rc) versions I perhaps ignorantly believed was an adapted FW version 'only' used by the spam companies. Host in question seen as a BS user for a year (not BS beta.)
The only co-relation I've seen between a handful of these (rc) hosts not using port 27016 is they all used high number ports between 53450 to 61919. The host with same address as the BS host who I see consistently has used multiple ports also within that range. I haven't added them to hostiles at this point. I don't have any evidence they're actually spamming.

GTK 1.0.0 for OSX tended to crash easily for me. GTK 1.0.1 crashes during closing. Same error each time.

As an addendum to this, I've spotted the same BearShare host address (but using LW_rc) using port 27016 over past two days. I don't think there's any excuse for this & points to a rogue BearShare user & probably multiple hosts running from same host address. As a LW-rc host, I noted countless ports used. And now the 27016. Some examples: 54569, 56373, 61919, 58280, 58227, 56097, 60437, 58658, 27016.
Until now, I thought it was simply a random connection port. But in retrospect, I recall seeing multiple ports in same day (6 ports used on 24 June, two on 26 June.) I doubt LimeWire/4.21.1 (rc) needs to be restarted that often in one day & in each case as an ultrapeer.
Edit September: Another one has appeared that is both (rc) & uses BS with similar shares.

History of the BearShare host: first sighted 21 June 2013, connected for about 24 hrs. Was a consistent user 24/7 every month up to now. Often had 1-9 days uptime. Shares: (3602/744 GB) by 25 June 2013. Though this varied from 716 GB to 791 GB over the year with shares up to 4020. On 14 February 2014 (1420/33 GB) but grew gradually up to 1725/128 GB) by 14 April, and (2098/244 GB) by 1 May.

BearShare Lite 5.2.5.1 - WinXP

The size of shares does not appear to match the average LimeWire/4.21.1 (rc) host, but then I haven't seen this particular host's shares whilst using LW-rc. Perhaps the BS objective was upload slot containment I wonder. Speculative.

(although I have temporarily banned a BS host more than once due to greed factor whilst using LPE, I can't remember which one now.)