Am Samstag, 7. November 2009 15:22:33 schrieb Michael Green:
> Gnutella2 has nothing to do with Gnutella -- it's a misnomer. Look for
> "Shareaza" instead.

Or just check the Gnutella specs:

- http://gnet-specs.gnufu.net

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - Ein Würfel System - einfach saubere Regeln -
                            http://1w6.org



[Non-text portions of this message have been removed]

Ali,

Gnutella2 has nothing to do with Gnutella -- it's a misnomer. Look for
"Shareaza" instead.

-- Mike

ali ashrafi wrote:
> Hi All
> is there any rfc of Gnutella2?
>

Hi All
is there any rfc of Gnutella2?


  thanks you beforehand.
----
Ali Ashrafi
M.Sc. Student
Department of Computer Engineering
Sharif University of Technology




[Non-text portions of this message have been removed]

Am Samstag, 31. Oktober 2009 13:19:49 schrieb Raphael_Manfredi@...:
> And how many do you see that still work on this project 4 months later?

That's a damn good question - and sadly none I can answer. I don't see it; and
I won't go investigating before I see them in my connections :)

Besides: Do you know something about "Foxy"?

> That would be a very bad idea.  Think about the implications, the
> bootstrapping problems, and the risk of creating a parallel network if
> too successful. :-)

The last part is the only real risk I see :)

> Features should be tested LOCALLY.  Use open-source servents to establish
> a small local network and attempt to join it (as a leaf node).

But that doesn't help in testing for the effects of the feature on a larger
real-life network.

> Now  creating a test lab environment is in itself a lot of work and most
> people will not bother, hence fail.

Which I see as a slightly suboptimal situation...

There are some scientific papers around with ideas for more efficient search
protocols which could be used in a single client and such, and it would be
nice if it was possible to test these without affecting the whole network with
a botched experiment.

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - singing a part of the history of free software -
               http://infinite-hands.draketo.de


[Non-text portions of this message have been removed]

Quoting Arne Babenhauserheide <arne_bab@...> from ml.gnutella.dev-forum:
:Am Samstag, 31. Oktober 2009 00:26:45 schrieb Raphael_Manfredi@...:
:> The fact is that the barrier of entry for Gnutella is now extremely high.
:> Nobody can sit down and write a new Gnutella servent in a matter of weeks.
:> One needs several years, I would say.
:
:I see many people who try, though. Alone during the last 4 months, two or
:three people asked for advice on their new Gnutella client in (insert
:programming language) in gnutellaforums.com (development section).

And how many do you see that still work on this project 4 months later?

:> Also it's not like there can be tons of new features developped, as in
:> the good old days (almost ten years ago).  With Gnutella getting more
:>  mature, new features are usually breakthroughs that can open a lot of new
:>  opportunities but which are complex to design, develop, test and deploy.
:
:Maybe we could lower the barrierfor testing new features in a live network by
:establishing a testing network.
:
:Do you think it would be feasible to add a testnet handshake to establish a
:seperate network where developers are free to try new ideas which could be
:harmful if they don't work out?

That would be a very bad idea.  Think about the implications, the
bootstrapping problems, and the risk of creating a parallel network if
too successful. :-)

Features should be tested LOCALLY.  Use open-source servents to establish
a small local network and attempt to join it (as a leaf node).  Now creating
a test lab environment is in itself a lot of work and most people will not
bother, hence fail.

Raphael

Hi Raphael,

Am Samstag, 31. Oktober 2009 00:26:45 schrieb Raphael_Manfredi@...:

> :PS: Could you write a few lines about major gtk-gnutella news since your
> : last DHT status update?

> Take the DHT for instance.  I'm in the process of completing the
>  development which I have started more than one year ago.  Hopefully, both
>  LimeWire and gtk-gnutella will be able to inter-operate constructively in
>  a few weeks, unleashing the full potential of the DHT structure.  This was
>  not fully perceived by users until now because the LimeWire implementation
>  of the DHT was not complete: it lacked final tuning which is about to be
>  done, finally, following the footsteps of gtk-gnutella.

That*'s the kind of informatin I meant - but I should have been more specific:
Which are the changes in GTKG which are relevant to other Gnutella developers.

> I guess there is little to exchange given that the Shareaza folks swear
> mostly by Mike's Protocol nowadays,

There's been some wikipedia vandalizing on that topic - the german wikipedia
Article on Gnutella said roughly "the Gnutella2 developers say that it scales
much besser, has much more efficient search mechanisms and can be extended far
easier" - I changed it to to "they claim it scaled better, had more efficient
search mechanisms and were easier to extend. The Gnutella developers disagree,
though" (I hope I got the time-forms right in the translation to english...).

> Phex is in sleeping mode

We're currently in "mostly bug fixing" mode - limited time.

But I have a news item which might be of interest to other Gnutella
developers: I'm (slowly) integrating a full-fledged python interpreter as
command line UI for Phex, so it will be easier for people to experiment with
Phex at runtime without having to dive deep into its code. Should you see
people using that for harmful stuff, please tell us (so we can add some
restrictions)!

Current state: The interpreter has access to the Phex API, but doesn't have a
real command interface - and it isn't yet in any release, so only people who
build from SVN can test it.

> The fact is that the barrier of entry for Gnutella is now extremely high.
> Nobody can sit down and write a new Gnutella servent in a matter of weeks.
> One needs several years, I would say.

I see many people who try, though. Alone during the last 4 months, two or
three people asked for advice on their new Gnutella client in (insert
programming language) in gnutellaforums.com (development section).

> Also it's not like there can be tons of new features developped, as in
> the good old days (almost ten years ago).  With Gnutella getting more
>  mature, new features are usually breakthroughs that can open a lot of new
>  opportunities but which are complex to design, develop, test and deploy.

Maybe we could lower the barrierfor testing new features in a live network by
establishing a testing network.

Do you think it would be feasible to add a testnet handshake to establish a
seperate network where developers are free to try new ideas which could be
harmful if they don't work out?

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - singing a part of the history of free software -
               http://infinite-hands.draketo.de


[Non-text portions of this message have been removed]

Hey,
> PPS: Is there a reason why this list is used for so little collaborative
> feature development these days?
>
Just a matter of time on my end. Doesn't mean I'm not watching the list
though! :)

-- Mike

Quoting Arne Babenhauserheide <arne_bab@...> from ml.gnutella.dev-forum:
:In short words: We have one header exchange per segment, so every bit in the
:header hurts performance much more than in webservers, and Link isn't
:standardized for our usecase. Correct?

Basically, yes.

:PS: Could you write a few lines about major gtk-gnutella news since your last
:DHT status update?

This is not a gtk-gnutella announce list.  You should subscribe to the
gtk-gnutella-devel list on sourceforge if you want to get news about the
development of GTKG.

I've posted information about the DHT implementation here because the DHT
is rather under-documented and I wanted to share the efforts of my
reverse-engineering the DHT implemented by LimeWire, in the hope that other
servent authors would find this information useful.

:PPS: Is there a reason why this list is used for so little collaborative
:feature development these days?

I guess there is little to exchange given that the Shareaza folks swear
mostly by Mike's Protocol nowadays, BearShare is almost dead, Phex is
in sleeping mode, Swapper is dead, gift-gnutella is dead, Gnucleus is
dead, etc...

The fact is that the barrier of entry for Gnutella is now extremely high.
Nobody can sit down and write a new Gnutella servent in a matter of weeks.
One needs several years, I would say.

Also it's not like there can be tons of new features developped, as in
the good old days (almost ten years ago).  With Gnutella getting more mature,
new features are usually breakthroughs that can open a lot of new opportunities
but which are complex to design, develop, test and deploy.

Take the DHT for instance.  I'm in the process of completing the development
which I have started more than one year ago.  Hopefully, both LimeWire and
gtk-gnutella will be able to inter-operate constructively in a few weeks,
unleashing the full potential of the DHT structure.  This was not fully
perceived by users until now because the LimeWire implementation of the DHT
was not complete: it lacked final tuning which is about to be done, finally,
following the footsteps of gtk-gnutella.

Raphael

Am Donnerstag, 29. Oktober 2009 23:02:37 schrieb Raphael_Manfredi@...:
> :Would there be merit in switching to that standard header?
>
> There could be a reason if we were still using the old
> X-Gnutella-Alternate-Location header.  But we switched to X-Alt
> for one single reason: bandwidth saving in the header exchanges.
>
> Contrary to a web server where HTTP headers are exchanged once per
> file downloaded, the swarming nature of Gnutella makes bandwidth
> consideration important.
...
> By comparison, X-Alt lists hosts that can supply an exact replicate of
> the resource.
...
> So I do not think it would be a good idea to support Link when talking to
> another Gnutella servent.  When talking to a browser, it could make sense
> to emit it, provided the value of the "rel" parameter is standard and
> unambiguous.  We would not want some servents to say rel="alt", others
> rel="alt-loc", others rel="x-alt"... you get the point.

Yes - many thanks!

In short words: We have one header exchange per segment, so every bit in the
header hurts performance much more than in webservers, and Link isn't
standardized for our usecase. Correct?

Best wishes,
Arne

PS: Could you write a few lines about major gtk-gnutella news since your last
DHT status update?

PPS: Is there a reason why this list is used for so little collaborative
feature development these days?

--- --- --- --- --- --- --- --- ---
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
- Arne (http://draketo.de)
--- --- --- --- --- --- --- --- ---



[Non-text portions of this message have been removed]

Quoting Arne Babenhauserheide <arne_bab@...> from ml.gnutella.dev-forum:
:I just found a blog post about the HTTP "Link" header:
:
:- http://changelog.ca/log/2006/06/17/gnutella_does_not_need_the_x-
:alt_http_header
:
:Example:
:
:Link: <http://192.0.2.44:6346/uri-
:res/N2R?urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214> ; rel="alternate"
:
:Would there be merit in switching to that standard header?

There could be a reason if we were still using the old
X-Gnutella-Alternate-Location header.  But we switched to X-Alt
for one single reason: bandwidth saving in the header exchanges.

Contrary to a web server where HTTP headers are exchanged once per
file downloaded, the swarming nature of Gnutella makes bandwidth
consideration important.

Also, the semantics of Link are open: one can express various things
with a Link header and create relations into closely related but not
necessarily identical items.

By comparison, X-Alt lists hosts that can supply an exact replicate of
the resource.

Following is the full Link specification from HTTP/1.1. Note that the
values of the link parameters are completely open and would therefore
need to be standardized for Gnutella to be able to emit these headers
and be understood properly.

19.6.2.4 Link

    The Link entity-header field provides a means for describing a
    relationship between two resources, generally between the requested
    resource and some other resource. An entity MAY include multiple Link
    values. Links at the metainformation level typically indicate
    relationships like hierarchical structure and navigation paths. The
    Link field is semantically equivalent to the <LINK> element in
    HTML.[5]

           Link           = "Link" ":" #("<" URI ">" *( ";" link-param )

           link-param     = ( ( "rel" "=" relationship )
                              | ( "rev" "=" relationship )
                              | ( "title" "=" quoted-string )
                              | ( "anchor" "=" <"> URI <"> )
                              | ( link-extension ) )

           link-extension = token [ "=" ( token | quoted-string ) ]

           relationship   = sgml-name
                          | ( <"> sgml-name *( SP sgml-name) <"> )

           sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )

    Relationship values are case-insensitive and MAY be extended within
    the constraints of the sgml-name syntax. The title parameter MAY be
    used to label the destination of a link such that it can be used as
    identification within a human-readable menu. The anchor parameter MAY
    be used to indicate a source anchor other than the entire current
    resource, such as a fragment of this resource or a third resource.

    Examples of usage include:

        Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"

        Link: <mailto:timbl@...>; rev="Made"; title="Tim Berners-Lee"

    The first example indicates that chapter2 is previous to this
    resource in a logical navigation path. The second indicates that the
    person responsible for making the resource available is identified by
    the given e-mail address.

So I do not think it would be a good idea to support Link when talking to
another Gnutella servent.  When talking to a browser, it could make sense
to emit it, provided the value of the "rel" parameter is standard and
unambiguous.  We would not want some servents to say rel="alt", others
rel="alt-loc", others rel="x-alt"... you get the point.

Raphael

Hi,

For a long time I wanted to create a Gnutella tracker which serves as
centralized alt-loc resource, but I only now have the coding skills to do so
:)

-> http://bitbucket.org/ArneBab/gnutella_tracker/

"A simple file-tracker for Gnutella You can put files into the 'files' folder
which then are made available via magnet links with alternate locations. Also
it implements the x-alt protocol to learn about more alternate locations."

To get the source, you can either use Mercurial

	 hg clone https://bitbucket.org/ArneBab/gnutella_tracker/

or just get the current snapshot:
-> http://bitbucket.org/ArneBab/gnutella_tracker/get/tip.zip

Just start it with

	 python gnutella_tracker.py

Please tell me if it works for you!

Best wishes,
Arne

PS: The reason for creating this centralized fileserver is to have a first
source of data, similar to what BitTorrent trackers provide.
Also Communities can from around fileservers (it's easy to disable the serving
of files and replace it with just storing the metadata).

PPS: If you just want to test how it works, the magnet on the following page
should allow you to download a test picture, as long as I keep the server
running (not quite sure how long that will be...):
- http://edrikor.dyndns.org:8000/

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - singing a part of the history of free software -
               http://infinite-hands.draketo.de



[Non-text portions of this message have been removed]

Hi,

I just found a blog post about the HTTP "Link" header:

- http://changelog.ca/log/2006/06/17/gnutella_does_not_need_the_x-
alt_http_header

Example:

Link: <http://192.0.2.44:6346/uri-
res/N2R?urn:sha1:4727ac07221adba9875a894738eeff9cc7fdd214> ; rel="alternate"

Would there be merit in switching to that standard header?

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - singing a part of the history of free software -
               http://infinite-hands.draketo.de


[Non-text portions of this message have been removed]

Frostwire is built using an older version of LimeWire's code.  The version
it is based off of supports Gnutella.

Sam

On Thu, Sep 17, 2009 at 3:38 AM, wolli_68 <wolli_68@...> wrote:

> Does anybody know whether Frostwire uses the Gnutella or the Gnutella2
> protocol (or both)
>
> Thanks
> Wolli
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

Does anybody know whether Frostwire uses the Gnutella or the Gnutella2 protocol
(or both)

Thanks
Wolli

--- In the_gdf@yahoogroups.com, Raphael_Manfredi@... wrote:
>
> Quoting rik_saunderson <rik.saunderson@...> from ml.gnutella.dev-forum:
> :Hi there,
> :I'm trying to understand how modern gnutella clients send and recieve control
> :messages (i.e. ping, pong, query, queryhit, push, bye and vendor specific).
> :Older clients send them over tcp on port 6346, but most modern clients (e.g.
> :Limewire, Frostwire etc.) no longer do this because it's incredibly easy to
block
> :with a firewall.  Additionally, some send control messages over UDP.
> :
> :I've looked on the Limewire wiki, and I've tried reading a spec for GUESS
that I
> :found, but I cant find an exact spec.
> :
> :My questions are these:
> :1.  How do modern gnutella clients agree on which port to use as the
destination
> :port?  It can't just be the Listen-IP filed of a GNUTELLA CONNECT because I
have
> :pcap files of transfers where this data does not appear.
>
> Yes, it is the value of Listen-IP or Node headers.
>
> Not all servents will send it out though, as it is not mandatory to initiate
> a connection (since you know the remote IP and port).
>
> :2.  Is there a spec document with the format of the most common vendor
specific
> :messages (i.e. bytes 0-15 are the servent ID, byte 16 is the length etc.)?
>
> Each vendor message will specify the meaning of its payload.
>
> For instance, here is the definition of the "GTKG/7v2" message:
>
>     Name: UDP Connect Back
>     Vendor: GTKG
>     ID: 7
>     Version: 2
>     TTL: 1
>     Payload:
>         unsigned short: port number (little-endian)
>
> You see, it clearly mentions that the payload is a single little-endian 2-byte
> word.
>
> :3.  Both of the above questions for UDP control messages.
>
> UDP control messages are simply Gnutella messages, there are no differences
> with the ones sent over TCP.
>
> Raphael
>
Hi,
  I want to know about manet & p2p filesharing application in nS2 simulator
environment.currently i am searching for the p2p protocols Mobile Peer to Peer
(MPP) & Optimised Routing Independent Overlay Network(ORION) protocol which are
obviously application layer protocol. I want to interface this application layer
protocol to
NS2 physicaql/network layer protocols.I don't have much knowledge about NS2 till
now So also tell me about the links & study material which I desperately need
for clearing my concepts regarding the same.
Please tell me where can I get these above mentioned protocols to interface with
the NS2.More information regarding this will be greatly appreciated

With thanks,
Mahesh

Hello,

I am new to this group so I don't know how to deal with this.Currently I am
working on NS2 simu8lations for file transfer applications in manet.For that i
am requiring a protocol ORION(optimised routing independent overlay netwok).How
to associate it with ns2 I don't know i.e. whether it's code file is to be
attached to ns2 also this is application layer protocol or what? is possible to
do simulations with NS2 using this protocol or not?
And mainly where shall I get the code of this protol for NS2 implementation in
NS2.

With thanks & regards,

Bhosale Mahesh





[Non-text portions of this message have been removed]

Raphael_Manfredi@... wrote:
> Quoting Daniel Cunha <daniel.ccunha@...
> <mailto:daniel.ccunha%40gmail.com>> from ml.gnutella.dev-forum:
> :The handshake and the ping and pong messages are working good,
> :apparently. The problem arrives when query messages are send, I receive
> :from the other side a message complaining about my packet size.
>
> Are you sure this is due to your query messages?

You are right, it wasn't. I realize that I used a method to send packets
that appends a "\n" at the end of the string.

> The length is properly little-endian encoded, and is correct (9 bytes).
> The minimum speed is correctly encoded as big-endian.
> The search criteria is correctly NUL-terminated.
>
> I do not see any error in that packet.

OK. Thanks, it works fine now.



Daniel Cunha

Quoting Daniel Cunha <daniel.ccunha@...> from ml.gnutella.dev-forum:
:The handshake and the ping and pong messages are working good,
:apparently. The problem arrives when query messages are send, I receive
:from the other side a message complaining about my packet size.

Are you sure this is due to your query messages?

:I wasn't able to identify the problem during the build of query packet.
:Well, the query is send like this one:
:
:           GUID: 16 bytes with random values
:   Payload Type: 0x80
:            TTL: 5
:           HOPS: 0
: Payload Length: 9
:  Minimum Speed: 0x8000
:Search Criteria: foobar (terminated by 0x00)
:
:When packet:
:
:"k\002\000\000\260\003\000\000\334\003\000\000*\000\000\000\200\005\000\t\000\0\
00\000\200\000foobar\000"
:(it's a ruby string)
:
:The byte size is 32.
:
:Any idea why my packets have errors?

The above serialized form looks fine, but then it's not easy to read such
a string with all the escapes.

Let's decompose the Gnutella header:

	 GUID: "k\002\000\000\260\003\000\000\334\003\000\000*\000\000\000"
	 Payload Type: "\200"
	 TTL: "\005"
	 Hops: "\000"
	 Payload Length: "\t\000\000\000"
	 Minimum Speed: "\200\000"
	 Search Criteria: "foobar\000"

The length is properly little-endian encoded, and is correct (9 bytes).
The minimum speed is correctly encoded as big-endian.
The search criteria is correctly NUL-terminated.

I do not see any error in that packet.

:Another question, there is any protocol extension that is vital to a
:good communication?

Vendor Messages, GGEP, Query Routing, compressed connections are pretty much
mandatory items in modern servents for Gnutella communications.

Raphael

Hi,


I'm studying a bit the gnutella protocol for academic purposes. Because
of this I'm trying to develop a simple servent that works only in leaf mode.

The handshake and the ping and pong messages are working good,
apparently. The problem arrives when query messages are send, I receive
from the other side a message complaining about my packet size.

I'm using Phex to test in a private network, from this servent I can see
that it closes the connection displaying the message: "Error. Packet too
big. Disconnecting the remote host".

LimeWire send me a packet with "Packet Size Greater than 32k".

I wasn't able to identify the problem during the build of query packet.
Well, the query is send like this one:

            GUID: 16 bytes with random values
    Payload Type: 0x80
             TTL: 5
            HOPS: 0
  Payload Length: 9
   Minimum Speed: 0x8000
Search Criteria: foobar (terminated by 0x00)

When packet:

"k\002\000\000\260\003\000\000\334\003\000\000*\000\000\000\200\005\000\t\000\00\
0\000\200\000foobar\000"
(it's a ruby string)

The byte size is 32.

Any idea why my packets have errors?

Another question, there is any protocol extension that is vital to a
good communication?


Thanks for any help,

Daniel Cunha

Am Montag, 28. September 2009 23:08:40 schrieb Michael Rogers:
> I'm surprised the URL is still getting hit if it no longer responds -
> I'm afraid some other client must have hardcoded it (it's definitely not
> in LimeWire's current list).

Does an access to the URL return a proper 404?

If not, some older versions might react by regularly testing, if it's back up
(I had that problem myself - the server *died* when I *removed* the GWC, since
my hoster used a nonstandard 404 - adding a clean 404 site fixed the problem).

Best wishes,
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
    - singing a part of the history of free software -
               http://infinite-hands.draketo.de

Hi Kirk,

That file no longer exists in the current version of the source, and
your URL was removed from the file in 2003, but I'm afraid we can't
remove it from the CVS history.

I'm surprised the URL is still getting hit if it no longer responds -
I'm afraid some other client must have hardcoded it (it's definitely not
in LimeWire's current list).

Cheers,
Michael

kirkawolff wrote:
> The url http://kirk.homeip.net/php/gwebcache/gcache.php is no longer active
and my webserver is constantly getting hit for no good reason.  AFAIK the main
origin of this activity is your hard-coded list of gwebecache servers.  Please
remove this from your source.  I see it in the following place:
>
>
https://www.limewire.org/fisheye/browse/~br=bugfix-340-branch/limecvs/components\
/gnutella-core/src/main/java/com/limegroup/gnutella/bootstrap/DefaultBootstrapSe\
rvers.java?r=1.8.2.1
>
> Thank you
>
> - Kirk
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

The url http://kirk.homeip.net/php/gwebcache/gcache.php is no longer active and
my webserver is constantly getting hit for no good reason.  AFAIK the main
origin of this activity is your hard-coded list of gwebecache servers.  Please
remove this from your source.  I see it in the following place:

https://www.limewire.org/fisheye/browse/~br=bugfix-340-branch/limecvs/components\
/gnutella-core/src/main/java/com/limegroup/gnutella/bootstrap/DefaultBootstrapSe\
rvers.java?r=1.8.2.1

Thank you

- Kirk

Quoting majortommib <majortommib@...> from ml.gnutella.dev-forum:
:I'm receiving a million+ requests/day while testing the Beacon php GWC code. 
To
:reduce the load on the server I've created two static result pages updated
every
:minute resulting in a significant reduction in cpu usage.
:
:Two questions, first given the concept behind the GWC, are results as old as
one
:minute acceptable and second are the changes I made working properly.

I cannot comment on whether your setup is doing what you want (i.e. that the
files are indeed updated once every minute only) but I can comment on whether
this is acceptable.

The answer is yes.

Instead of setting up GWCs, you should however provide UHCs and make their
hostname:port available to Gnutella vendors for bootstrapping reasons.

Some Gnutella vendors like gtk-gnutella chose (with very valid reasons) to
no longer support GWCs anyway, so they are neither queried nor updated.  Only
UHCs are used for bootstrapping, and only when the local hostcache, filled by
previous runs, is not enabling reconnection to the network.

Raphael

I'm receiving a million+ requests/day while testing the Beacon php GWC code.  To
reduce the load on the server I've created two static result pages updated every
minute resulting in a significant reduction in cpu usage.

Two questions, first given the concept behind the GWC, are results as old as one
minute acceptable and second are the changes I made working properly.

The top two requests were ?get=1... and ...hostfile=1, so using .htaccess I used
rewrite to serve two different static files.  A cron job runs every minute to
update the result files:

.htaccess file:

AddType x-mapp-php5 .php
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} gwc.php
RewriteCond %{QUERY_STRING} ^get=1
RewriteRule ^ /get.txt
RewriteCond %{REQUEST_FILENAME} gwc.php
RewriteCond %{QUERY_STRING} hostfile=1$
RewriteRule ^ /hostfile.txt

cron entries (edited):

* * * * * curl -o hostfile.txt
"http://beacon.technutopia.net/gwc.php?client=TEST1.0&hostfile=1"
* * * * * curl -o get.txt
"http://beacon.technutopia.net/gwc.php?client=TEST1.0&get=1"

The two servers I'd like verified as are

http://beacon.technutopia.net/gwc.php
http://s298220357.onlinehome.us/gwc.php

Thanks in advance for reviewing and/or testing these servers.

I was wondering who to blame! ;-)

-- Mike
> Hi Folks,
>
> I'm sorry that this spam message got through.

Hi Folks,

I'm sorry that this spam message got through.

gracielapo@... is now moderated.

Besides: When new people post, their posts need to be approved.  I approve all
messages which seem Gnutella related, but when people post questions about how
to use a certain program, I point them to the corresponding forum or website
(I didn't have to do that very often).

Best wishes,
Arne

PS: If you have any comments on the moderation, please tell me!

Am Sonntag, 13. September 2009 14:48:28 schrieb ...:
> ...spam...


[Non-text portions of this message have been removed]

                
         Brand Online wholesale
            USA CA  AU   UK   Eur




















 




This email is sent in accordance with the US CAN-SPAM Law in effect 01/01/2004.
Removal requests can be sent to this address and will be honored and respected.
            
                 


      
________________________________________________________________________________\
____
¡Todo sobre la Liga Mexicana de fútbol! Estadísticas, resultados, calendario,
fotos y más:
http://espanol.sports.yahoo.com/

[Non-text portions of this message have been removed]

Completely true: Hole punching does not even require that an active session is
established with a third party. On
many routers is is just enough to punch a free port in order to open or maintain
a forwarding rule within the
router, in order for incoming packets (including incoming session requests) to
reach the intended peer bhing the
firewall or proxy.

TLS by itself requires initiating a session with a third party, but the
condition for it is that it must be
reachable, so any intermediate router must still be traversed successfully. Hole
punching is there to help the
intermediate routers to maintain an active route to the peer behind the proxy or
firewall.

By itself, hole punching offers no security, no authentication. It is just used
by the router to indicate that
there's a peer listening on that port, and that is ready to accept any random
packet sent from unknown remote sites.
It also indicates to the router to which host on the local private LAN to
forward these incoming packets. So hole
punching works in a way similar to UPnP forwarding rules, but it will work where
UPnP is not usable or not
implemented by the router.

The bad thing about hole punching is that this punching is temporary and it must
be renewed regularly, as long as
the forwarding rule has not been used by some other active session or other
incoming/outgoing UDP traffic using the
same pair of ports. Today, hole punching is deprecated and should not be used if
UPnP is available, but UPnP has its
own caveats: its forwarding rule will remain mostly perfmanently within the
router, even if the intended recipient
is no longer active and another unrealted port may be used without notive by
another unrelated program : in fact it
is not different from manually registering a port forwarding rule within the
router.

Well-behaved UPnP-compatible servers should discard their UPnP forwarding rule
when the server is being shutdown.
Using UPnP is more economical in terms of bandwidth and stability than hole
punching, which is really a trick that
will generally work only on non-UPnP routers, but UPnP-compatible routers should
ignore the hole punching technic,
for security reasons, if their UPnP capability is already enabled.

TLS is unrealted here: it has nothing to do in terms of protocols within the
router. The router perceives any TLS
session as a normal TCP session, and it just just maintain the port forwqarding
rule as long as the TCP session is
active. There's no direct support of TLS in routers over a sessionless transport
like UDP, even if TLS could be
supported by emulating TCP over a UDP channel (in that case, UPnP port
forwarding or hole punching or any kind of
UDP traffic over the UDP chennel, including no-op, ping-like traffic, will
maintain the port forwarding in order to
support the session emulation).

So why are you speaking about TLS here? It's just because TLS is typically used
in the context where a server is not
directly reachable with active hole punching of its own router, or its own UPnP
configuration of its local router,
or by manual configurtion of a static forwarding rule in ots local router. In
that case, the server will have to
open an active session permanently to another proxy host found somewhere on the
Internet and reachable there. TLS
will be used to secure the traffic between the proxy and that firewalled server.
The TLS session will remain active
as long as the firewalled server is there. In that case, this TLS session is
transparent to the other random clients
somewhere else on the Internet, that will only see the proxy.

another use of TLS will be transparent for the proxy, but can be used in
end-to-end sessions forwarded by the proxy:
the random clients and the proxied server will just communicate through a
VPN-like secured channel, that the proxy
does not need to authenticate and manage itself. In that case, TLS will be used
to anonimize the traffic between the
random clients and the server, so that even the proxy will not be able to
inspect the state of communications
secured through the forwarded session.

All these are general considerations, they are not specific to Gnutella, but are
related to network topologies and
infrastructures and the level of security implied in each trafic forwarding
domain managed by various (unknown)
third-parties.

> Message du 07/09/09 09:21
> De : Raphael_Manfredi@...
> A : the_gdf@yahoogroups.com
> Copie à :
> Objet : [the_gdf] Re: File downloading
>
>
> Quoting rik_saunderson  from ml.gnutella.dev-forum:
> :How do common implementations of hole punching and TLS work? Am I correct in
> :thinking that Hole Punching and Push Proxying are one and the same thing? If
> :not, how does it actually work in a gnutella context?
> :What's the process by which two servents engage in a TLS file transfer?
>
> Hole Punching and TLS are two orthogonal concepts.
>
> The process by which two servents engage in a TLS file transfer is that the
> connecting party issues a TLS request to the other TLS-enabled servent.
> It knows that the remote servent is TLS-enabled due to the presence of
> TLS indication in query hits, head pongs, push, alt-locs, etc....
>
> Raphael
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>
>

Quoting rik_saunderson <rik.saunderson@...> from ml.gnutella.dev-forum:
:How do common implementations of hole punching and TLS work?  Am I correct in
:thinking that Hole Punching and Push Proxying are one and the same thing?  If
:not, how does it actually work in a gnutella context?
:What's the process by which two servents engage in a TLS file transfer?

Hole Punching and TLS are two orthogonal concepts.

The process by which two servents engage in a TLS file transfer is that the
connecting party issues a TLS request to the other TLS-enabled servent.
It knows that the remote servent is TLS-enabled due to the presence of
TLS indication in query hits, head pongs, push, alt-locs, etc....

Raphael

How do common implementations of hole punching and TLS work?  Am I correct in
thinking that Hole Punching and Push Proxying are one and the same thing?  If
not, how does it actually work in a gnutella context?
What's the process by which two servents engage in a TLS file transfer?

The donloader sends a query message.  The uploader sends a query hit.  Something
happens and then the uploader sends the downloader the file over TLS.  What's
the bit in the middle?
Thanks,
Rik

--- In the_gdf@yahoogroups.com, Raphael_Manfredi@... wrote:
>
> Quoting rik_saunderson <rik.saunderson@...> from ml.gnutella.dev-forum:
> :I am trying to understand modern implementations of the gnutella protocol,
and
> :I'm having problems understanding newer methods of file downloading.
>
> You got it correctly.  The hardest part is getting the HTTP/1.1 protocol
> correctly.  Don't forget that HTTP/1.1 implies support for persistent
> connections and chunked transfer encoding.  Don't forget to output the
> proper Content-Length headers on your 200 replies and Content-Range on
> your 206 replies.
>
> You need to be HTTP/1.1 compliant plus handle all the Gnutella-specific
> headers with their proper semantics (e.g. X-Alt, X-NAlt, X-Hostname, etc...).
>
> :Observing file transfer in Wireshark, I sometimes don't see any of the above.
I do see:
> :GET /client_startup, which is presumably a message sent by the client on
startup.
> :GET /p.xml where p.xml is an xml file
>
> No idea what the above is.  It does not look like a Gnutella transfer to me.
>
> :My question is, have I interpreted the last two correctly, and are there
other
> :ways of downloading files that I haven't been able to find?
>
> There is only ONE way to download files: through HTTP/1.1.  After that, you
> have several URN structures to handle to map the requested resource.  Note
that
> a magnet: is a URI, and therefore cannot be used to download directly.  It
> needs interpretation to find the proper URLs to request.
>
> I'm sure you realize this is going to be a huge implementation effort to
> get something robust.  There's a lot of plumber work to do before you can
> even start getting something useful done.
>
> Raphael
>