gtk-gnutella-devel Digest, Vol 19, Issue 4

[gtk-gnutella-devel-request]

Send gtk-gnutella-devel mailing list submissions to
        gtk-gnutella-devel@...

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
or, via email, send a message with subject or body 'help' to
        gtk-gnutella-devel-request@...

You can reach the person managing the list at
        gtk-gnutella-devel-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gtk-gnutella-devel digest..."


Today's Topics:

   1. Re:  BearShare is too aggressive or it's so widely spreaded?
      (general hosts quality issue) (Christian Biere)
   2.  Normal (old-style) connections count like ultranodes or
      leaves count (gionnico)
   3.  Bandwidth's measurement is completely wrong (maybe
      relative?) (gionnico)
   4. Re:  Normal (old-style) connections count like ultranodes or
      leaves count (Christian Biere)
   5. Re:  Bandwidth's measurement is completely wrong (maybe
      relative?) (Christian Biere)
   6. Re:  Bandwidth's measurement is completely wrong (maybe
      relative?) (Bill Pringlemeir)
   7. Re:  Bandwidth's measurement is completely wrong (maybe
      relative?) (Christian Biere)
   8.  gtk-gnutella crash (on missing font?) (Meelis Roos)


----------------------------------------------------------------------

Message: 1
Date: Sat, 12 Jan 2008 00:20:33 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] BearShare is too aggressive or it's
        so widely spreaded? (general hosts quality issue)
To: gtk-gnutella-devel@...
Message-ID: <20080111232033.GA29532@cyclonus>
Content-Type: text/plain; charset=us-ascii

gionnico wrote:
> It's strange but every time I connect if I don't force any connection I
> find to be connected almost only to BearShare ultrapeers.

As said this is probably a side-effect of LimeWire hating BearShare and
BearShare loving BearShare. I'm not certain but I also think LimeWire
passes mainly non-LimeWire addresses to non-LimeWire peers. Or maybe some
other vendor did that, I didn't check the code. LimeWire also supports
locale (language) preferencing which especially for smaller countries
can quickly degenerate the network even if implemented "carefully".
 
> And the cache becomes full of bearshare nodes.

Another big factor causing this might be the lack of preventing that
the cache is predominantly fed from a single peer. BearShare presumely
generates more gossip than LimeWire, causing it to fill your cache
with BearShares. Regardless of this specific observation, it's advisable
to accept only n peer addresses per time frame from any peer. This is
trivial to implement. Picking the right numbers could be more difficult.

> To avoid this I've had to set a 50% percentage in the connection setup
> for the allowed unique useragents.
> This makes a lot of hosts fail until it finds other nodes (usually
> LimeWire).

That's not a bad idea. It just cannot be enforced for everyone because
LimeWire makes up for far more than 50%. It also takes additional bandwidth
and time which not everyone is willing to spend, so it's disable by
default.

> I don't think this is normal, rather that bearshare spams only its nodes
> and maybe also too much of them.

Spamming is likely a too strong term, if not actually incorrect. At least
it should not matter, if gtk-gnutella did the right thing.

> Another problem is the bootstrap: I think it there should be a field
> that lets you choose the proxy-cache and very much better would be to
> have a gtk-gnutella with a minimum QA (I'm not talking about clustering,
> I'm talking about avoiding leechers and spam).

I guess with "proxy-cache" you mean a bootstrap server aka hostcache. You can
kind of do this by putting addresses (IP addresses or hostnames) with port
numbers into ~/.gtk-gnutella/whitelist. You can also prefix the addresses with
"tls:" to request TLS encryption. The term "whitelist" is misleading but what
isn't? gtk-gnutella will try to establish a connection to any listed peers. If
the peer is not an ultrapeer or already full, it should receive a couple
addresses from it. There are gtk-gnutella peers which publish their hostname.
You can see this in the result details if you come across results from any. You
can potentially use these as anchor peers.

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet



------------------------------

Message: 2
Date: Sun, 20 Jan 2008 22:18:15 +0100
From: gionnico <gionnico@...>
Subject: [gtk-gnutella-devel] Normal (old-style) connections count
        like ultranodes or leaves count
To: gtk-gnutella-devel@...
Message-ID: <4793BA97.2030209@...>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

This may be not so important.
But I personally think that old-style connections shouldn't be detracted
from the maximum number of ultranodes connections.

This just because I think it should be counted like the ultra/leaf: they
are separated.


And why to allow only one?
It's really a too little value, isn't it?
I mean what's the probem allowing 10 connections eg?
That value should depend on the user's bandwidth, shouldn't it?


And now a more general question about old-style/new-style : is there any
other client that supports both?
And so, is gtk-gnutella one of the few links between these two networks?
Or - even if it supports both - gtk-gnutella can't act as a bridge?
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Fai squillare la PANTERA ROSA sul tuo cellulare: e' in REGALO
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=6613&d=20-1



------------------------------

Message: 3
Date: Sun, 20 Jan 2008 22:31:15 +0100
From: gionnico <gionnico@...>
Subject: [gtk-gnutella-devel] Bandwidth's measurement is completely
        wrong (maybe relative?)
To: gtk-gnutella-devel@...
Message-ID: <4793BDA3.5050004@...>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed

That is.

I've seen this many times.

The bandwidth that gtk-gnutella measures isn't real.

If I sum http+gnutella+leaves I don't get the usage that I can measure
with a program like iftop, ifstat or conky (I don't know if conky uses
another program, though).

It turns out to be about 30-50% of the real used bandwidth.

And it's not about tcp-acks: the problem is the same even when I'm not
downloading, so that the acknowledgements for the same gnutella network
are negligible.

Parentethical I don't know but I think that acks should be included anyways.
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Vuoi avere un sito che incrementi il tuo business e porti nuovi clienti?
* Icecube.it ha tutte le strategie per la miglior visibilita' rispetto a quella dei tuoi concorrenti
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=7352&d=20-1



------------------------------

Message: 4
Date: Sun, 20 Jan 2008 22:57:01 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Normal (old-style) connections count
        like ultranodes or leaves count
To: gtk-gnutella-devel@...
Message-ID: <20080120215701.GC13207@cyclonus>
Content-Type: text/plain; charset=us-ascii

gionnico wrote:
> This may be not so important.
> But I personally think that old-style connections shouldn't be detracted
> from the maximum number of ultranodes connections.

> This just because I think it should be counted like the ultra/leaf: they
> are separated.

> And why to allow only one?

One or zero, it does not make much of a difference. Only outdated
software from 2002 or stuff hacked together by hostile parties still
(try to) operate in legacy mode.

> It's really a too little value, isn't it?
> I mean what's the probem allowing 10 connections eg?

It's not so much of a problem as it is a waste of bandwidth. Legacy peers
don't support filtered query routing, so they just forward everything,
even queries which cannot match anything of the receiver.

> That value should depend on the user's bandwidth, shouldn't it?

It depends on what you consider more important: Sharing files or running
an ultrapeer.
 
> And now a more general question about old-style/new-style : is there any
> other client that supports both?

Shareaza is the only software I know of which definitely supports legacy
peers.

> And so, is gtk-gnutella one of the few links between these two networks?
> Or - even if it supports both - gtk-gnutella can't act as a bridge?

Nobody cares about legacy peers anymore and I can't really tell how much of
that still works. It's not rocket science to implement at least leaf mode,
if someone considers implementing ultrapeer mode too complicated.

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet



------------------------------

Message: 5
Date: Sun, 20 Jan 2008 23:16:37 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Bandwidth's measurement is
        completely wrong (maybe relative?)
To: gtk-gnutella-devel@...
Message-ID: <20080120221637.GD13207@cyclonus>
Content-Type: text/plain; charset=us-ascii

gionnico wrote:
> The bandwidth that gtk-gnutella measures isn't real.
 
> If I sum http+gnutella+leaves I don't get the usage that I can measure
> with a program like iftop, ifstat or conky (I don't know if conky uses
> another program, though).
 
> It turns out to be about 30-50% of the real used bandwidth.
 
> And it's not about tcp-acks: the problem is the same even when I'm not
> downloading, so that the acknowledgements for the same gnutella network
> are negligible.

I think in ultrapeer mode the measurements get increasingly off with the
amount of leaves. I assume the difference is caused by TCP-ACKs though. Why
do you think it isn't? For file transfers in either direction TCP-ACKs
should be mostly negligible because the payload outweighs the control
traffic. For Gnutella traffic, this isn't necessarily true because many
leaves may just send/receive an occassional packet with little payload and
the TCP-ACK is comparatively large and may not be piggy-backed either.

> Parentethical I don't know but I think that acks should be included anyways.

The problem is, that happens on layer to which we have almost no access and all
interfaces which exists to those layers typically require super-user
privileges. In theory, most of your traffic might consist of retransmitted
segments and ACKs but on our layer, we see none of that, we only see the
effective payload and its transfer rates.

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet



------------------------------

Message: 6
Date: Sun, 20 Jan 2008 22:48:22 -0500
From: Bill Pringlemeir <bpringle@...>
Subject: Re: [gtk-gnutella-devel] Bandwidth's measurement is
        completely wrong (maybe relative?)
To: gtk-gnutella-devel@...
Message-ID: <BAYC1-PASMTP08523DE7F09050BED65E6EB83D0@...>
Content-Type: text/plain; charset=us-ascii


gionnico wrote:
 
>> It turns out to be about 30-50% of the real used bandwidth.

On 20 Jan 2008, christianbiere@... wrote:

> The problem is, that happens on layer to which we have almost no
> access and all interfaces which exists to those layers typically
> require super-user privileges. In theory, most of your traffic might
> consist of retransmitted segments and ACKs but on our layer, we see
> none of that, we only see the effective payload and its transfer
> rates.

Do we count the IP headers?  That is tough, because it could be PPPxx
with IP layer compression, etc.  My guess is that gtkg count the
payload bytes only.

I have definitely set my bw setting emprirically.  Ie, I look at iftop
output and change gtkg bw limits to get near saturation of the link.
The gtkg limits are lower than the actual bw consumed.

fwiw,
Bill Pringlemeir.




------------------------------

Message: 7
Date: Mon, 21 Jan 2008 18:03:11 +0100
From: Christian Biere <christianbiere@...>
Subject: Re: [gtk-gnutella-devel] Bandwidth's measurement is
        completely wrong (maybe relative?)
To: gtk-gnutella-devel@...
Message-ID: <20080121170311.GB18233@cyclonus>
Content-Type: text/plain; charset=us-ascii

Bill Pringlemeir wrote:
> On 20 Jan 2008, christianbiere@... wrote:
 
> > The problem is, that happens on layer to which we have almost no
> > access and all interfaces which exists to those layers typically
> > require super-user privileges. In theory, most of your traffic might
> > consist of retransmitted segments and ACKs but on our layer, we see
> > none of that, we only see the effective payload and its transfer
> > rates.
 
> Do we count the IP headers?  That is tough, because it could be PPPxx
> with IP layer compression, etc.  My guess is that gtkg count the
> payload bytes only.

gtk-gnutella counts the payload only albeit it takes 20 bytes of TCP
header overhead into account somewhere. It would be possible to include
some overhead for each $MTU bytes sent and maybe even add some assumed
overhead for ACK packets in the opposite direction. Like-wise, for every
established inbound and outbound connection, some SYN/ACK overhead could
be assumed. Maybe this would gain more realistic measurements.

It doesn't require privileges to get some status information from any
network interface but unfortunately this information typically includes
LAN traffic. This means those values are fairly useless in the general
case as throughput could be drastically overestimated.
 
> I have definitely set my bw setting emprirically.  Ie, I look at iftop
> output and change gtkg bw limits to get near saturation of the link.

I also adjust the settings based on the current situation. If other network
activities seem significantly affected, I just reduce the bandwidth limit
for HTTP traffic.

> The gtkg limits are lower than the actual bw consumed.

--
1000 octets   = 1 ko = 1 kilooctet; 1024 octets   = 1 Kio = 1 kibioctet
1000^2 octets = 1 Mo = 1 megaoctet; 1024^2 octets = 1 Mio = 1 mebioctet
1000^3 octets = 1 Go = 1 gigaoctet; 1024^3 octets = 1 Gio = 1 gibioctet



------------------------------

Message: 8
Date: Wed, 30 Jan 2008 13:44:25 +0200 (EET)
From: Meelis Roos <mroos@...>
Subject: [gtk-gnutella-devel] gtk-gnutella crash (on missing font?)
To: gtk-gnutella-devel@...
Message-ID: <Pine.SOC.4.64.0801301246540.27977@...>
Content-Type: text/plain; charset="iso-8859-15"

I looked over my search results and after clicking on Alt-C to clean
current search rulsts and the clicking on aother sear, the new search
did not appear and gtk-gnutella was hung for several seconds and then
crashed, with messages like this in parent terminal. Looks like a crash
from pango on missing Hangul font?? Running debian sarge with gtk2 and
pango from that era.

08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
(gtk-gnutella:8845): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'(gtk-gnutella:8845): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
08-01-30 12:45:10 (WARNING): /usr/lib/pango/1.4.0/modules/pango-hangul-fc.so: cannot open shared object file: No such file or directory
Failed to load Pango module for id: 'HangulScriptEngineFc'
(gtk-gnutella:8845): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed
08-01-30 12:45:10 (CRITICAL): _pango_engine_shape_shape: assertion `PANGO_IS_FONT (font)' failed

Pango-ERROR **: file shape.c: line 75 (pango_shape): assertion failed: (glyphs->num_glyphs > 0)
aborting...
CRASH (pid=8845) by SIGABRT

and gdb backtrace is here too:
(gdb) bt
#0  0xb7f92410 in ?? ()
#1  0xbf9e1a7c in ?? ()
#2  0x00000006 in ?? ()
#3  0x0000228d in ?? ()
#4  0xb7823811 in raise () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7824fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7aecefd in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#7  0xb7aecf26 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#8  0xb7aed011 in g_main_context_find_source_by_user_data () from /usr/lib/libglib-2.0.so.0
#9  0xb7ba1c3c in pango_font_mask_get_type () from /usr/lib/libpango-1.0.so.0
#10 0xb7b97949 in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0
#11 0xb7b97ecd in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0
#12 0xb7b97fbc in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0
#13 0xb7b9871c in pango_layout_index_to_pos () from /usr/lib/libpango-1.0.so.0
#14 0xb7b96b86 in pango_layout_new () from /usr/lib/libpango-1.0.so.0
#15 0xb7b96ef7 in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0
#16 0xb7b96f84 in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0
#17 0xb7d0c136 in gtk_cell_renderer_pixbuf_new () from /usr/lib/libgtk-x11-2.0.so.0
#18 0xb7d0c4c1 in gtk_cell_renderer_pixbuf_new () from /usr/lib/libgtk-x11-2.0.so.0
#19 0xb7d06c63 in gtk_calendar_select_month () from /usr/lib/libgtk-x11-2.0.so.0
#20 0xb7ea1a24 in _gtk_tree_view_column_autosize () from /usr/lib/libgtk-x11-2.0.so.0
#21 0xb7e8eef5 in gtk_tree_store_new () from /usr/lib/libgtk-x11-2.0.so.0
#22 0xb7e8f5fc in gtk_tree_store_new () from /usr/lib/libgtk-x11-2.0.so.0
#23 0xb7e8cd96 in gtk_tree_sortable_sort_column_changed () from /usr/lib/libgtk-x11-2.0.so.0
#24 0xb7e8de34 in gtk_tree_store_reorder () from /usr/lib/libgtk-x11-2.0.so.0
#25 0xb7dc399e in gtk_list_item_new_with_label () from /usr/lib/libgtk-x11-2.0.so.0
#26 0xb7b509c9 in g_closure_add_marshal_guards () from /usr/lib/libgobject-2.0.so.0
#27 0xb7b50736 in g_closure_add_finalize_notifier () from /usr/lib/libgobject-2.0.so.0
#28 0xb7b61855 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#29 0xb7b60c8c in g_signal_get_invocation_hint () from /usr/lib/libgobject-2.0.so.0
#30 0xb7b61126 in g_signal_chain_from_overridden () from /usr/lib/libgobject-2.0.so.0
#31 0xb7eb2d87 in gtk_ui_manager_remove_ui () from /usr/lib/libgtk-x11-2.0.so.0
#32 0xb7dc12dd in gtk_list_select_item () from /usr/lib/libgtk-x11-2.0.so.0
#33 0xb7c4f5d9 in gdk_window_clear_area () from /usr/lib/libgdk-x11-2.0.so.0
#34 0xb7c4f72e in gdk_window_clear () from /usr/lib/libgdk-x11-2.0.so.0
#35 0xb7c4f3c5 in gdk_window_get_update_area () from /usr/lib/libgdk-x11-2.0.so.0
#36 0xb7ae7583 in g_key_file_get_locale_string_list () from /usr/lib/libglib-2.0.so.0
#37 0xb7ae4582 in g_key_file_has_group () from /usr/lib/libglib-2.0.so.0
#38 0xb7ae55f8 in g_key_file_get_groups () from /usr/lib/libglib-2.0.so.0
#39 0xb7ae5930 in g_key_file_error_quark () from /usr/lib/libglib-2.0.so.0
#40 0xb7ae5ed3 in g_key_file_has_key () from /usr/lib/libglib-2.0.so.0
#41 0xb7dc0bb3 in gtk_list_unselect_all () from /usr/lib/libgtk-x11-2.0.so.0
#42 0x0815d684 in main_gui_run (
    geometry_spec=0x815cb00 "U\211?\203?\b\213E\020\203?\bwB\213\025d\0246\b?d\0246\b?h\0246\b\205?u\004\211?]?\211\024$1?\211D$\004??????E\f\001") at main.c:692
#43 0x0807b33d in main (argc=1, argv=0x0) at main.c:1418


--
Meelis Roos (mroos@...)

------------------------------

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

------------------------------

_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@...
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel


End of gtk-gnutella-devel Digest, Vol 19, Issue 4
*************************************************