Re: Ultrapeer Status "UP" GGEP question
[email protected] Sun, 19 Apr 2009 20:37:02 +0000 (UTC)
| Newsgroups | gmane.network.gnutella.devel |
|---|---|
| Organization | Home, Grenoble, France |
| Message-ID | <[email protected]> |
Quoting pitermagram <[email protected]> from ml.gnutella.dev-forum: :Hi, : :i have the following question about "UP" ggep: : :in LimeWire client sources when this ggep parsed/created first comes ultrapeer :version, then amount of free leaf slots and third comes amount of free ultrapeer :slots: :(see attached part of source code) :payload[0] = 0; :payload[1] = localPongInfo.getNumFreeLimeWireLeafSlots(); :payload[2] = localPongInfo.getNumFreeLimeWireNonLeafSlots(); : :while in GTK Gnutella client first comes ultrapeer version, then amount of free :ultrapeer slots and third comes amount of free leaf slots (NOTE: ultrapeer and :leaf slots are switched): :(see attached part of source code) :ggep_stream_write(&gs, &meta->version_up, 1) && :ggep_stream_write(&gs, &meta->up_slots, 1) && :ggep_stream_write(&gs, &meta->leaf_slots, 1) && : :Is there any reason for this ? Yes, the reason is that gtk-gnutella follows the published specifications! The following page: http://wiki.limewire.org/index.php?title=Known_GGEP_Extension_Blocks defines the "UP" extension payload as: {VersionGuessStyle VersionUP, byte SlotsFreeUP, byte SlotsFreeLeaf} Note that the specification does not tell us what "versionUP" means, hence this is open to interpretation. Gtk-gnutella uses the minor version of the QRP protocol, i.e. 2 (as it supports 0.2). Raphael