I realise this is now an old thread and last reply 18 months ago but feel a growing desire to point out some issues. I've been putting together custom host files for some of the gnutella apps since the start of the decade (if not earlier.) I discovered some issues early on that still appear to be an issue now. I find this every time I put together a fresh host file (these days generally six monthly.)
Whenever I check the gnutella.net file used by all of the LIME code based programs there are numbers of hosts that are between 4 to 8 months old. How can I be sure that they are this old? One clue is them using dynamic ip addressing which expires after 3 or 6 weeks in cases of some ISP's. When I check the last time either WireShare or Phex have connected to the host it shows that suggested age of many months. What's alarming about this is that the hosts are often listed up around the top (or bottom should I say where the most recent hosts are added ~ within about the bottom 20 hosts.) My WireShare is used 24/7 with sessions lasting between one to three weeks.
How can a host not seen for 6 months be considered for sharing to other hosts? There might be more than one reason. I suspect the built-in system (GTK, LIME, etc.) sharing of hosts might be flawed. What happens if a host that has not used the network for half a year becomes an ultrapeer after an hour or few hours? Is it only sharing hosts recently discovered or is it also sharing hosts from a back-log of 6+ months ago?
I am aware GTK dates DHT hosts. I've also seen transactions where a host was dated as being between one to six days of age (though I don't know if the age of a host was due to GTK or WireShare's process or both.)
I first started working on the BearShare host file in 2011 and after a year or two I started to discover old hosts being added to the BearShare host file that had not been seen for over a year or even up to 3 years. Even at that time I had become aware of some ISP's that either used highly dynamic ip or relatively short-term Sticky Dynamic ip addressing of 3 or 6 weeks. I saw examples of the same hosts being included on the host file between 6 to 10+ times with different addresses. Again, some not seen for over a year or two. I originally wondered/suspected if one or more GWC's were at fault.
45.63.110.*:41481,86400,1497359030241,,15089234184 07;1508809867708;1508664928045,en,,0,ACTIVE,, (connection dates: 25 May 2017 to 13 June 2017)
Listed 9th on WireShare's gnutella.net host file yet not on hostiles & only ever sighted twice. None of the 7 Phex host files from 25 Sep-8 Nov lists this host. Nor any of the 6 files from 23 Aug-24 Sep. A host is distributing incorrect/out-of-date data or is this host really active?
Also 88.151.72.*:63667,86400, gtk-gnutella not sighted since 21 May & only seen since 15 May. Host address is Austria ISP Mag. Erwin Leitner & is a dynamic range. Another, 91.64.242.*:28049,86400, gtk-gnutella last sighted 14 Aug, first sighted 25 July. Germany Vodafone Kabel Deutschland & is dynamic. Their ip’s only last a few weeks from memory. So why is this and many other hosts being listed so high up the G file list & listed as 24/7.
Examples:
Code:
88.151.72.*:63667,86400,1495681316639,,1508933411336;1508719732959;1506572085087,en,,0,ACTIVE,1, (20 May) (Mag. Erwin Leitner - Dynamic)
91.64.242.*:28049,86400,1502918026837,,1508923985831;1508664996939;1506572268360,en,,0,ACTIVE,, (14 Aug) (Vodafone Kabel Deutschland - Dynamic)
133.218.*.*:15079,86400,1496181869553,,1508923453829;1508809986063;1506572042733,ja,,0,PASSIVE,, (connected to on & off between 21 Jan-5 July 2017)
172.76.165.*:10978,86400,1495406533334,,1508923413511;1508664818817;1504159857914,en,,,,, (never connected to ~ though might be recent, shows how dynamic ip addressing can cause out-of-date caching.)
172.76.174.*:10978,86400,1495393650331,,1508923482354;1508661777310;1506572124135,en,,,,, (never connected to ~ though might be recent, shows how dynamic ip addressing can cause out-of-date caching.)
24.0.*.*:53219,79569,1501091127350,,1508927017210;1508809911001;1508665008756,en,,0,ACTIVE,, (connected to on & off between 27 June to 15 July 2017)
2.29.21.*:42175,71765,1495636758996,,1508923514413;1508664699736;1506572064230,en,,0,PASSIVE,1, (connected to on & off between 15 to 24 May 2017; I’m not aware of many ip addresses starting with 2. as long-lifespan.)
I could keep going through the host file but feel I've made my point.
(ip addresses edited with * for privacy purposes.)
What is possibly alarming is that a very large number of these hosts are GTK-Gnutella hosts. But this is probably coincidental.
Question is, is this purely due to the possibility of PyGnutella or other reasons?
At least the PyGnutella ip ranges you listed are on the WSHR/LIME hostiles I use so in theory no direct contact should be possible.
One thing I like about the Phex host file management system is it caches around 95% of connected ultrapeer hosts to file, updating every 5 minutes. So it does give a good snapshot of a small section of the network at any given time.
Off-topic:
I often used to see GTK-Gnutella struggle to download files (from an observation point of view as an uploader.) But GTK versions since at least early 2016 I suspect might have fixed this issue because the only occasions I've seen it since are those using older GTK versions of a few years ago.
I recall last decade the upload topography might change every day or two. One day it might be mostly audio files, day or two later video or image files, etc. Presently I share 46% audio files but without exaggeration 5% or less of my uploads are audio. Has something changed?