Quote:
Originally posted by Moak
And how do you download? The problem is: Without more servants that accept incoming connections you have to trust on Pushs very often. But Pushs won't work bewteen two firewalled host (or better say bewteen two servants that can not handle incoming connections). When you see current Limewire host statistics [1], only few servants do accept incoming connections and on those the network file transfar relies IMHO.
For sure it's good to find alternative ideas.  I didn't get the useful addition to the Superpeer concept, could you explain please? How a bout the "superpong" mentioned in another thread, did you think that's a good idea?
[1] Rolling Host Count http://www.limewire.com/index.jsp/size |
Well, okay, maybe this last thing was not really justified. The problem of downloading something from a firewalled host will still be there.
This whole thing raises one question: What the heck is meant by 'incoming connections'? Do they (Limewire) mean attempted http-connections (download reqquests) or do they mean attempted Gnutella connections?
But, no matter what they do mean, I still think that the big difference between the number of unique hosts and that of the hosts accepting incoming connections on their host count is not mainly because so many hosts are firewalled, but rather because every node has a maximum number of connections (For Gnutella- as well as for http-connections), which, most of the time, are simply full.
About 'useful addition to the Supernode concept':
If you tried to connect to Gnutella as a Clientnode, you'd have a large list of IPs which you try to connect to one after the other, to find out that behind this IP/Port is one of the following:
a: No response because this node has already gone offline
b: No response because this node is an older Gnutella servent which doesn't even know about the existance of the Clientnode->Supernode protocol (btw, does such a thing already exist?)
c: A Clientnode
d: A Supernode which has already reached its maximum number of incoming Clientnode connections
or, finally
e: A Supernode which will happily accept your incoming connection request
To find a host of type e might probably take up to half an hour, especially in the the early days, if you only have a raw host list with no further information about the indexed hosts. If you, though, have more descriptiv information, you will find a suitable host a lot sooner. The whole thing could already be useful in a Gnutella net as it exists now (without Supernodes/Clientnodes).
About Superpong:
There were a lot of misunderstandings in this thread. When I first started it, I thought the main purpose of ping-pong was to give the nodes a rough figure about the number and size of the available files, the acquisition of new IPs only being a side effect, so I posted a method which would serve this purpose without providing the nodes with even one single new IP.
However, the main difference between the superpong idea, which emerged from that other discussion and the idea about the high quality host lists is, that while the latter focusses mainly on which information should be available about individual hosts and how it should be used, the first one focusses rather on how this information should be spread across the network.
My solution to the latter problem was to append this information to some query or query replies every one and then, as it is described in that 'HUGE'-RFC by the GDF. I think this is a better idea, because we wouln't have to introduce a new message type for this.
Guido