GTK reactions versus BearShare

Lord of the Rings · #1 (**permalink**) December 31st, 2015

When I run the BearShare 5.1.0.25 Beta without being firewalled as an ultrapeer, I get mixed results from GTK ultrapeers. Some give a message saying not a gnutella member, some auto-ban my ip address, yet at some stage a GTK or more might even connect with my BearShares. There appears to be a lack of consistency.

Code:

Auto Host x.x.x.x:xxxx ("gtk-gnutella/1.1.8 (2015-12-18; GTK2; Linux x86_64)") dropped: response code: 403 'Not a network member'
-- Handshake 1 OUT --
.... (abilities check)
-- Handshake 2 IN --
GNUTELLA/0.6 403 Not a network member\r\n
etc.

I can understand GTK not wishing to connect with BearShare due to its very old gnutella technology; lack of deflate & other search handling/cache & connection abilities & approach.

Code:

Auto Host x.x.x.x:xxxx ("gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux i686)") dropped: response code: 550 'Hostile IP address banned'
-- Handshake 1 OUT --
GNUTELLA CONNECT/0.6\r\n
.... (abilities check)
-- Handshake 2 IN --
GNUTELLA/0.6 550 Hostile IP address banned\r\n
User-Agent: gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux i686)\r\n
Remote-IP: x.x.x.x\r\n
X-Live-Since: Tue, 22 Dec 2015 20:40:32 -0600\r\n
\r\n

Banning the ip address? That's a bit severe!

I'm almost slightly amused because the GTK peer auto-banning my ip I presume also blocks all communications with my ip. That means anywhere up to 15,000 files shared between my three apps (two presently 24/7) will be inaccessible to this GTK host. Also with one app running in DHT, I presume this might also affect both this GTK & possibly it's leafs search results.

I don't mind freeloaders auto-banning me though.

One side-effect of auto-ban is it possibly affecting BearShare's UDP & TCP packet testing.

Code:

Auto Host x.x.x.x:xxxx ("gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux x86_64)") dropped: response code: 403 'Not a network member
'
-- Handshake 1 OUT --
GNUTELLA CONNECT/0.6\r\n
User-Agent: BearShare 5.1.0b25\r\n
.... (abilities check)
-- Handshake 2 IN --
GNUTELLA/0.6 403 Not a network member\r\n
User-Agent: gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux x86_64)\r\n
Remote-IP: x.x.x.x\r\n
\r\n

This one is same version (except it's 64-bit) as the one that auto-banned yet it responds with a 403 message instead.

Now the extra step of inconsistency:

gtk-gnutella/1.1.8 (2015-12-18; GTK2; Linux x86_64) connected to both of the BearShare's. So did gtk-gnut/1.1.7 (2015-12-13; Lin)

The BearShare community is incredibly small these days; nearing extinction. A year ago up to mid-year this year the number of UP's seen over a week was around 15, now it's around or under 10. Half of those are non-firewalled. Unfortunately it saddens me to see the 24/7 BS UP's are firewalled BS5.1Beta users using forced-UP mode. I can understand GTK blocking out the firewalled UP's, but perhaps a little disappointing the non-firewalled UP's are treated with contempt!
Even the BS leaf population has shrunk from between 300-400 connections between peers down to around 60 or less since a year ago.

Lord of the Rings · #2 (**permalink**) January 13th, 2016

Observations in the previous post are not a new concept, I'd been seeing the same thing for a couple of years now.

Some days after the above post I noticed yet another reaction to BearShare which was no doubt due to the same GTK-G. being connected to WS. GTK-G. gave an exception & passed some hosts.

Code:

Auto Host x.x.x.x:xxxxx ("gtk-gnutella/1.1.5 (2015-10-08)") dropped: response code: 409 'Already connected
'
-- Handshake 1 OUT --
GNUTELLA CONNECT/0.6\r\n
User-Agent: BearShare 5.1.b25\r\n
X-Requeries: false\r\n
Vendor-Message: 0.1\r\n
X-Ultrapeer: True\r\n
X-Query-Routing: 0.1\r\n
Machine: 1,8,559,1,3190\r\n
Pong-Caching: 0.1\r\n
Listen-IP: x.x.x.x:xxxx\r\n
Remote-IP: x.x.x.x\r\n
GGEP: 0.5\r\n
X-Degree: 26\r\n
X-Ultrapeer-Query-Routing: 0.1\r\n
X-Max-TTL: 4\r\n
X-Dynamic-Querying: 0.1\r\n
X-Probe-Queries: 0.1\r\n
X-Features: chat/0.1\r\n
Accept-Encoding: deflate\r\n
\r\n

-- Handshake 2 IN --
GNUTELLA/0.6 409 Already connected\r\n
User-Agent: gtk-gnutella/1.1.5 (2015-10-08)\r\n
Remote-IP: x.x.x.x\r\n
X-Token: Vo…….W; 5…+/S…=\r\n
X-Try-Ultrapeers: x.x.x.x:27016, x1.x.x.x:27016, x4.x.x.x:3xxx3,\r\n
	x.x.32.x:xxxxx, x6.x1.x.x:xxx9\r\n
\r\n

2nd occasion with different GTK host:

Code:

Auto Host x.x.x.x:xxxxx ("gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux i686)") dropped: response code: 409 'Already connected
'
-- Handshake 1 OUT --
GNUTELLA CONNECT/0.6\r\n
User-Agent: BearShare 5.1.b25\r\n
...
-- Handshake 2 IN --
GNUTELLA/0.6 409 Already connected\r\n
User-Agent: gtk-gnutella/1.1.6 (2015-11-08; GTK2; Linux i686)\r\n
X-Token: Vo….fw==\r\n
X-Live-Since: Mon, 04 Jan 2016 18:20:22 -0600\r\n
X-Try-Ultrapeers: x.x.x.x:xxxxx, x.x.x.x:xxxxx, x.x4.x7.x9:xxxx,\r\n
	x.x.x.x:xxxxx, x.x.x.x:xxxx, y.x.x.x:xxxx,\r\n
	x.x.x.x:xxxx, x.x.x.x:xxxxx, x.x.x.x:xxxxx,\r\n
	x.x.x.x:xxxx\r\n
\r\n

Comment: All good hosts.

Nice to see GTK contribute hosts toward BS even if this was one of those exceptions.

Two comments:
1. Disappointing to see BOTs are not filtered out.
2. I can't recall if I were using BS or WS early 2015 but the log showed hosts anywhere up to 6 days of age being received from GTK-G hosts (the host's age was listed.) In this day & age, that means the host address in question might have changed (I've even seen GTK peers change address over ten times during a week.) Pointless continuing to cache them once they go offline. (Checking a GWC I noticed the same BS host listed multiple times with different addresses since the GWC lists multiple days. I can see a similar problem with handing out older host data.)

It had been a concept of mine to introduce a Dynamic address filter to WS but I can perhaps find another project to add it to. If a host within known highly dynamic addressing is no longer online, there's no point in keeping it cached (or passing out that host's details.)

The LIME based programs give minimal importance to recording connected hosts to the host-file. Typically only about 6% of a LIME based host-file have ever been connected to over a period of months. It's no surprise their host-file quickly becomes outdated when the greatest source of host data is via gifts of host data.

Phex is far more practical because it bases its host-file upon connected hosts. Phex's management is probably the best on the network with the host-file remaining relevant for the longest.
Whilst I can think of a Phex improvement using date, the question is why fix something that is highly reliable & not broken.

h4x5h17 · #3 (**permalink**) January 16th, 2016

Among my many tasks with Phex, one is to create simple source code matrix.
Just a text or html document (in tree format) that lists all source files and what they do.
Also included would be showing which sources import or extend other sourses and which ones are included in different packages.

The more you are exposed to Phex code the less important something like this is. But for new devs (to Phex and Java) it could be very useful for digging in.