Quote:
|
1. I’m curious, what is the search horizon with this system?
|
Unlike Gnutella queries travel only 1 hop, but to compensate for that the fan-out factor is much higher. I've set it to 512 now, although that might bump into some built-in I2P limits.
So theoretical maximum for an Ultrapeer would be 512 * 512 * 512 + 512 = 134218240 but of course in reality it would be much, much lower.
Quote:
|
2. How long can a search be expected to run for? (I'm never sure if the search has finished or not.)
|
There is no dynamic querying so there is no way to know when a search has ended, but in reality queries reach the entire network very quickly. If you are receiving many results back from a single responder that could take a bit more time. I would say 20 seconds maximum, give or take.
Quote:
|
. How many peers does a leaf expect to connect to? Or does i2p use a different system?
|
Leafs are not implemented yet
so everyone atm is an ultrapeer. Now, MuWire connections are different from I2P-level connections (you can see those in Status->I2P). I2P connections are capped depending on configured bandwidth but max out at close to 2000. For MuWire-level connections you will basically try to connect to everyone you learn about, and there aren't that many nodes on the network right now.
Quote:
|
. I presume the program has UPnP support? I setup port forwarding after a short period of time. I presume the MuWire port will remain the same.
|
UPnP is "outsourced" to the I2P router. It tries to map a random TCP and UDP port, which you should be able to change through the settings. However, all the firewall traversal business is handled by I2P as well; nobody at the MuWire layer is firewalled, so everyone can be an ultrapeer.
As for the other suggestions I agree the library management can be improved a lot and I will get to it eventually. The first public release was just a few months ago as you can see from the git history.