03/11/2014
What was said in freenode #gtk-gnutella on 03/12/2014:
- 00:58:49
Unit193
left the channel
- 01:01:34
Unit193
joined the channel
- 01:04:08
ArneBab_
left the channel
- 01:06:18
ArneBab
joined the channel
- 02:23:08
rootatlocalhost
rootatlocalhost will now be known as r00t-
- 03:41:28
ArneBab_
joined the channel
- 03:44:34
ArneBab
left the channel
- 04:32:31
Ci-Dev
joined the channel
- 04:35:18
Ci-Dev_
left the channel
- 06:30:43
mrjoe[w]
left the channel
- 07:18:39
mrjoe[w]
joined the channel
- 08:04:19
ram:
mrjoe[w]: morning
- 08:04:38
ram:
Here are some specs I wrote this morning for something I plan to implement in gtk-gnutella:
- 08:04:40
ram:
http://g2.doxu.org/index.php/QH2#.2FQH2.2FG1_-_Gnutella-Relayed_Query_Hit
- 08:04:53
ram:
Comments welcome if you believe something is missing or could be amended
- 09:20:14
ArneBab_
left the channel
- 13:23:38
bluemeanie
left the channel
- 13:29:25
bluemeanie
joined the channel
- 13:29:30
bluemeanie
left the channel
- 15:06:48
ArneBab
joined the channel
- 15:10:22
mrjoe[w]
left the channel
- 17:15:43
mrjoe[w]
joined the channel
- 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
- 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.
- 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?
- 17:29:56
ram:
(the one receiving the QH2)
- 17:30:06
mrjoe[w]:
Those are unknown ;) But in the initial handshake the node expresses whether it supports g2 doesn't it?
- 17:30:46
mrjoe[w]:
For non gnutella clients, they know they don't need to attempt a g2 push
- 17:32:33
mrjoe[w]:
I asume gtk-gnutella sends Accept: application/x-gnutella2 9otherwise it wouldn't connect to a hub
- 17:32:46
ram:
Yes, but only when it wants a hub connection
- 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?
- 17:36:06
mrjoe[w]:
Or isn't that understood?
- 17:37:12
ram:
we don't support quality in the accept, no.
- 17:37:34
ram:
And since GTKG is a Gnutella client, it always prefers Gnutella connections.
- 17:37:38
mrjoe[w]:
Or without the quality, just in order of precendence
- 17:37:42
ram:
We don't even parse quality :-)
- 17:39:03
mrjoe[w]:
In that case you'd know whether g2 was supported& oh well
- 17:39:41
ram:
Exactly, but the question is more: why would it matter?
- 17:39:58
ram:
Because even if G2 is supported, that does not mean the node is connected to G2 hosts
- 17:40:18
ram:
(at least the ones listed in the Query Hit as push-proxies)
- 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
- 17:43:07
ram:
Absolutely. that proxy will be working
- 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
- 17:44:39
mrjoe[w]:
I see
- 17:50:10
mrjoe[w]:
In that case the use is limited
- 17:52:15
ram:
the use of?
- 17:52:26
mrjoe[w]:
Indicating wether G2 is supported
- 17:52:40
ram:
indeed :-) That's why I was enquiring what you had in mind.
- 17:53:22
ram:
For unfirewalled sources, this will be completely transparent to G2 clients, even if they don't parse the /QH2/G1
- 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
- 17:54:36
ram:
Hence, in general, the scheme appears safe... on paper. Now I need to code all that logic.
- 17:55:57
mrjoe[w]:
And when g2 support is finished, it is time for g3 ;)
- 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
- 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.
- 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?
- 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.
- 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)
- 18:01:54
mrjoe[w]:
Why not make it configurable via the shell
- 18:01:59
mrjoe[w]:
(or is it already?)
- 18:02:13
ram:
It's possible already, and I have cron jobs that do that for me here.
- 18:02:14
mrjoe[w]:
So one can just use a simple cronjob to pipe the new bandwith values into gtkg
- 18:02:24
ram:
But he runs on Windows
- 18:02:27
mrjoe[w]:
O
- 18:02:41
mrjoe[w]:
Maybe he'd better upgrade to something else ;)
- 18:03:12
mrjoe[w]:
Or maybe we need to extend gtkg to support powershell&
- 18:03:34
ram:
For the average Windows user, or even average UNIX user, that feature would be nice anyway.
- 18:03:56
mrjoe[w]:
Yes, but a simpler version like transmission for example sound better in those cases
- 18:04:16
ram:
transmission?
- 18:04:30
mrjoe[w]:
See this screenshot how they do it: http://www.transmissionbt.com/images/screenshots/Qt-Large.jpg
- 18:05:38
ram:
Hah yes, much simpler for a first version
- 18:05:49
mrjoe[w]:
And understandable for the average joe
- 18:06:06
ram:
And covers 95% of the needs
- 18:12:19
mrjoe[w]:
Perhaps if we could do rpc on windows, we could cover the other 5%
- 18:16:14
mrjoe[w]:
http://www.gnutellaforums.com/gtk-gnutella-linux-unix-mac-osx-windows/102639-older-gtk-gnutella-versions-should-they-trusted.html , sounds like what you have mentioned before.
- 19:09:13
ram:
Yes, looks like it. Replying
- 19:15:29
mrjoe[w]
left the channel
- 00:00:00
--- ---