The most efficient gnutella client.


What was said in freenode #gtk-gnutella on 03/12/2014:

  1. 00:58:49 Unit193 left the channel
  2. 01:01:34 Unit193 joined the channel
  3. 01:04:08 ArneBab_ left the channel
  4. 01:06:18 ArneBab joined the channel
  5. 02:23:08 rootatlocalhost rootatlocalhost will now be known as r00t-
  6. 03:41:28 ArneBab_ joined the channel
  7. 03:44:34 ArneBab left the channel
  8. 04:32:31 Ci-Dev joined the channel
  9. 04:35:18 Ci-Dev_ left the channel
  10. 06:30:43 mrjoe[w] left the channel
  11. 07:18:39 mrjoe[w] joined the channel
  12. 08:04:19 ram: mrjoe[w]: morning
  13. 08:04:38 ram: Here are some specs I wrote this morning for something I plan to implement in gtk-gnutella:
  14. 08:04:40 ram:
  15. 08:04:53 ram: Comments welcome if you believe something is missing or could be amended
  16. 09:20:14 ArneBab_ left the channel
  17. 13:23:38 bluemeanie left the channel
  18. 13:29:25 bluemeanie joined the channel
  19. 13:29:30 bluemeanie left the channel
  20. 15:06:48 ArneBab joined the channel
  21. 15:10:22 mrjoe[w] left the channel
  22. 17:15:43 mrjoe[w] joined the channel
  23. 17:17:58 mrjoe[w]: Hello ram, I was wondering if it might be usefull for QH2/G1 to have a payload indicating whether G2 is supported, not suppported or unknown
  24. 17:29:02 ram: mrjoe[w]: how do you compute that? As an UP, you're connected to the leaf using G1, so it's going to be hard.
  25. 17:29:38 ram: We have a cache of course, and we could lookup there, but what good is it going to do to the other party?
  26. 17:29:56 ram: (the one receiving the QH2)
  27. 17:30:06 mrjoe[w]: Those are unknown ;) But in the initial handshake the node expresses whether it supports g2 doesn't it?
  28. 17:30:46 mrjoe[w]: For non gnutella clients, they know they don't need to attempt a g2 push
  29. 17:32:33 mrjoe[w]: I asume gtk-gnutella sends Accept: application/x-gnutella2 9otherwise it wouldn't connect to a hub
  30. 17:32:46 ram: Yes, but only when it wants a hub connection
  31. 17:36:00 mrjoe[w]: So we don't use something like accept: application/x-gnutella;q=1,application/x-gnutella2;q=0.5 for example?
  32. 17:36:06 mrjoe[w]: Or isn't that understood?
  33. 17:37:12 ram: we don't support quality in the accept, no.
  34. 17:37:34 ram: And since GTKG is a Gnutella client, it always prefers Gnutella connections.
  35. 17:37:38 mrjoe[w]: Or without the quality, just in order of precendence
  36. 17:37:42 ram: We don't even parse quality :-)
  37. 17:39:03 mrjoe[w]: In that case you'd know whether g2 was supported& oh well
  38. 17:39:41 ram: Exactly, but the question is more: why would it matter?
  39. 17:39:58 ram: Because even if G2 is supported, that does not mean the node is connected to G2 hosts
  40. 17:40:18 ram: (at least the ones listed in the Query Hit as push-proxies)
  41. 17:41:49 mrjoe[w]: but the ultrapeer relaying the query will know how to forward a g2 push, so it has a known push node
  42. 17:43:07 ram: Absolutely. that proxy will be working
  43. 17:43:39 ram: It's the other /QH2/NH that will be listed (the original push-proxies sent by the leaf) that may be only supporting Gnutella
  44. 17:44:39 mrjoe[w]: I see
  45. 17:50:10 mrjoe[w]: In that case the use is limited
  46. 17:52:15 ram: the use of?
  47. 17:52:26 mrjoe[w]: Indicating wether G2 is supported
  48. 17:52:40 ram: indeed :-) That's why I was enquiring what you had in mind.
  49. 17:53:22 ram: For unfirewalled sources, this will be completely transparent to G2 clients, even if they don't parse the /QH2/G1
  50. 17:54:11 ram: For firewalled sources, normally a /PUSH will be sent by UDP to all the /QH2/NH nodes, at which point the relaying ultrapeer will be contacted and will route
  51. 17:54:36 ram: Hence, in general, the scheme appears safe... on paper. Now I need to code all that logic.
  52. 17:55:57 mrjoe[w]: And when g2 support is finished, it is time for g3 ;)
  53. 17:58:36 ram: One thing that a colleague desperately wants is a way to graphically program different b/w configurations depending on the time of the day and the day of the week
  54. 17:59:13 ram: So that he can run full-speed and even as UP during the night, but as leaf and with lower settings during daytime.
  55. 18:00:38 mrjoe[w]: SO for each day he'd like to have a different start and end time and different b/w limit?
  56. 18:01:01 ram: Seems like a good thing, but what scares me is the amount of GUI work required to do that. Plus I want the GUI config to be translated into a parseable language for people who don't like GUIs, or for headless nodes.
  57. 18:01:36 ram: Basically, yes, he wants some flexible configuration (depends on his working hours -- he works mostly from home, when he needs the bandwidth for work)
  58. 18:01:54 mrjoe[w]: Why not make it configurable via the shell
  59. 18:01:59 mrjoe[w]: (or is it already?)
  60. 18:02:13 ram: It's possible already, and I have cron jobs that do that for me here.
  61. 18:02:14 mrjoe[w]: So one can just use a simple cronjob to pipe the new bandwith values into gtkg
  62. 18:02:24 ram: But he runs on Windows
  63. 18:02:27 mrjoe[w]: O
  64. 18:02:41 mrjoe[w]: Maybe he'd better upgrade to something else ;)
  65. 18:03:12 mrjoe[w]: Or maybe we need to extend gtkg to support powershell&
  66. 18:03:34 ram: For the average Windows user, or even average UNIX user, that feature would be nice anyway.
  67. 18:03:56 mrjoe[w]: Yes, but a simpler version like transmission for example sound better in those cases
  68. 18:04:16 ram: transmission?
  69. 18:04:30 mrjoe[w]: See this screenshot how they do it:
  70. 18:05:38 ram: Hah yes, much simpler for a first version
  71. 18:05:49 mrjoe[w]: And understandable for the average joe
  72. 18:06:06 ram: And covers 95% of the needs
  73. 18:12:19 mrjoe[w]: Perhaps if we could do rpc on windows, we could cover the other 5%
  74. 18:16:14 mrjoe[w]: , sounds like what you have mentioned before.
  75. 19:09:13 ram: Yes, looks like it. Replying
  76. 19:15:29 mrjoe[w] left the channel
  77. 00:00:00 --- ---