View Single Post
  #2 (permalink)  
Old January 13th, 2016
Lord of the Rings's Avatar
Lord of the Rings Lord of the Rings is offline
ContraBanned
 
Join Date: June 30th, 2004
Location: Middle of the ocean apparently (middle earth)
Posts: 619
Lord of the Rings has a distinguished reputationLord of the Rings has a distinguished reputationLord of the Rings has a distinguished reputation
Default

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.
Reply With Quote