here are some changes those are not explained in the helpfiles.

------------------------------
On Postman's tracker you'll find them on this sites:

Details for torrent pool: "I2PSnarkXL"
http://tracker2.postman.i2p/index.php?view=TPoolDetail&id=118

i2psnarkxl-20090427a.zip
http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=3358

i2psnarkxl-20090508a.zip
http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=3425

i2psnarkxl-20090522a.zip
http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=3593

------------------------------------------------------------------
Patchcrackinfo:  	20090427a
Language: 	multi
OS: 	java
Genre: 	i2p bittorrent client
Description: 	adding PaTracker

nothing else
--------------
this version will not working with i2p versions less than 0.7-7
see: what and why
http://forum.i2p/viewtopic.php?p=14836

i2psnarkxl-20090427a.zip

md5: 83815ea6c53e8d678e7cbfec00cced77

the zip-archiv including the source, examples and all other neccessaries
(and a snapshot of the current project page in the help directory)

for installing

see: the readmeFirst.txt
and
eepSite: http://i2psnarkxl.i2p/faq.html#install
and the included help folder 
------------------------------------------------------------------
Patchcrackinfo:  	20090508a
Language: 	multi
OS: 	java
Genre: 	i2p bittorrent client
Description: 	adding gchan tracker
fixing the experminental-[search]-option for PaTracker torrents on classic page (long filenames end with "..." and couldn't be found)
--------------
this version will not working with i2p versions less than 0.7-7
see: what and why
http://forum.i2p/viewtopic.php?p=14836

i2psnarkxl-20090508a.zip

md5: 397cefc203af512b7b3db05d16e9cc48

the zip-archiv including the source, examples and all other neccessaries
(and a snapshot of the current project page in the help directory)

for installing

see: the readmeFirst.txt
and
eepSite: http://i2psnarkxl.i2p/faq.html#install
and the included help folder

------------------------------------------------------------------
Patchcrackinfo:  	20090522a
Language: 	multi
OS: 	java
Genre: 	i2p bt client
Description: 	beta release ...................

- adding a http-proxy tunnelbuild class to xl (ProxyHttpClient.class)
- adding option settings for the http-proxy (classic-page)
- removing dead-trackers

usage:
open the classic page and change
"Configuration: EepProxy port: " - change the port to a suitable number
"Configuration: Use XL-Proxy:checkbox" - select enable
save the config

xl automatic open a seperate http-proxy for each client for the tracker access now

for more details to change the options for the included xl-http-proxy by your own copy the "i2psnarkxl-proxy.config" of the zip archiv (i2p-folder) to your i2p-install folder.
all your xl bt-clients using that file for setting up the http-proxy options.
nickname and port settings are overwritten by the application with the settings of classic-page-configuration during xl is running.

see more and discuss it at:
http://forum.i2p/viewtopic.php?p=17361
--------------
this version will not working with i2p versions less than 0.7-7
see: what and why
http://forum.i2p/viewtopic.php?p=14836

i2psnarkxl-20090522a.zip

md5: 49975c19ca8814548c42ce2e1566de96

the zip-archiv including the source, examples and all other neccessaries
(and a snapshot of the current project page in the help directory)

for installing

see: the readmeFirst.txt
and
eepSite: http://i2psnarkxl.i2p/faq.html#install
and the included help folder 
------------------------------------------------------------------
##################################################################
http://forum.i2p/viewtopic.php?p=17361 

- Just as Info -

Guest wrote:
Problem descirption (free abreviated translation):

in i2p every app gets its own set of tunnels in order to provide unlinkability not only to physcal persons but also unlinkability between different services or different 'avatars' - thus to prevent profiling.

If you download something via i2p internal bittorrent you use a http proxy for communication with the tracker.
Now if you use the same eepProxy for that as for your normal browsing, then your browsing and your downloads are linkable again.
This is against the principles of i2p.
Also if you use verious instances of a bittorrent client and make them seem to be different users, then you feel safe, but lose this unlinkability between them clients as long as they use the same eepProxy.

End of problem description.



BIG thanks at "guest" for the translation!
------------------------------------------

german: http://forum.i2p/viewtopic.php?t=3497


fwd wrote:


Um was geht's?
Es geht darum wie snark sich mit dem Tracker verbindet, bisher dachte ich das snark sich die Informationen des trackers über die normale Destination (i2p-ip) des BT-Clienten besorgt.
Leider ist dies nicht der Fall!
Die Informationen werden über "eepget" via unserem normalen HTTP-Proxy geholt. Soweit ja nicht weiter schlimm, aber für Leute die mehrere BT-Clients benutzen und verschiedene "Avatare" als Uploader beim Tracker benutzen ist die geglaubte Anonymität natürlich weg! Allerdings nur beim Trackerbetreiber (falls ihn/sie das überhaupt interessiert!).

Um diesem Anonymitätsverlust entgegen zu wirken musste ich mich sehr tief mit der Tunnel-Bildung in I2P selbst beschäftigen. Da ich davon bisher keine Ahnung hatte war dies mit einem hohem Zeitaufwand verbunden, aber zu guter letzt hat es dann doch irgendwie geklappt.

I2PSnarkXL benutzt auf userwunsch nun eigene, seperate http-tunnel als proxies, somit bleibt die Anonymität bei mehreren BT-Client erhalten. Diese können auch zum normalen surfen benutzt werden (wenn man es den will ...).

Da das Proxy erst mit dem starten von torrents in i2psnarkxl aktiviert wird, kann es am Anfang zu Verbindungsproblemen mit dem tracker führen, dies ist aber nach ein paar Minuten vorüber.

Bei Benutzung des XL-Http-Proxies muss man ab jetzt allerdings umbedingt auf die Port Einstellungen achten und ändern! Nicht den Port 4444 des normale http-proxies nehmen sonst kommt es zu Konflikten! Also im "Classic" Page den "EepProxy - Port" ändern UND bei jedem XL-Clienten unterschiedliche port nummern eintragen! Will man das XL-Http-Proxy nicht benutzen muss man wieder den normalen Port (4444) eintragen.

Die Änderungen gelten ab Version "20090522a" die ich noch im Laufe des Tage (oder erst in der Nacht) uploaden werde, falls ich die Übersetzung ins englische einigermassen hinbekomme, da die Beschreibung des Problems schon in deutsch schwer genug ist und es einige vermutlich gar nicht verstehen und bestimmt noch einige Anfragen mit dem Port-Settings in Zukunft zu erwarten sind. Sorry, lässt sich leider nicht vermeiden, ... der Anonymität zuliebe!



greetz fwd
##############################################################################
------------------------------------------------------------------------------

2010, Mai, 5

This I2PSnarkXL version includes some changes i've done over the past year

Patchcrackinfo:  	20100504a
Language: 	multi
OS: 	java
Genre: 	i2p bt client
Description: 	beta release ...................

- changing the behaviour of the xl-html-proxy
 now i made sure that we got a new html-proxy destination too when we change our BTClient-destination by "stop all"

- search function on classicpage working even when a torrent include "http://tracker2.postman.i2p/announce.php" insteed of the long i2p.ip

- dataloss operating working by default only on the incompletes files now
 the long period since including the dataloss workaround shows that it is mostly not neccessary to checking the completed files for errors.
 but you can changes that to checking all files again by changing the parameter "check.incomplete.only=true" to "check.incomplete.only=false" in the configfile for every xl-client.

- refix the known Robert id's since it was changed in time by the dev.

- adding 2 new themes "az1" and "Postman" and some fixes in others
 ( why nobody else preparing some new themes?! it isn't that kind of complicated to make a own theme! isn't it for you? )

 do not forget to copy the new "i2P/templates/..." AND the new "i2p/doc/themes/i2psnarkxl/..." of the zipfile to your i2p-install folder!

- and ... few things i've forgotten yet

the zip-archiv including the source, examples and all other neccessaries
(and a snapshot of the current project page in the help directory)

for installing

see: the readmeFirst.txt
and
eepSite: http://i2psnarkxl.i2p/faq.html#install (if online)
and the included help folder 

greetz fwd
##################################################################################
stable release ...................

- including a "Seed Swarm Service"
The Seed Swarm Service allows you to seed the same file(s) with a group of xl-clients without making multiple physical copies of the file(s).
read the help files before you use the seed swarm service!

- include fixed Postman theme
- zmeta datas in the config file are removed when a file is removed too
- adding the "detail" link of torrents like previous known from the old postman tracker too
and some others minor stuff

i2psnarkxl-20100517a.zip

md5: b2243c2f6e7bd29eb29c534c8308842d

the zip-archiv including the source, examples and all other neccessaries
(and a snapshot of the current project page in the help directory)

for installing

see: the readmeFirst.txt
and
eepSite: http://i2psnarkxl.i2p/faq.html#install (if online)
and the included help folder

i can not test the themes on every browser, so ...
Please report any problems! (screenshots might help a lot!)

greetz fwd
http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=7821
##################################################################################
Welchen Sinn macht ein Seed Swarm? (I2PSnarkXL)

Erweiterung des HowTos "Seed Swarm Service" und damit der Text auch im deutschsprachigem Teil des Forums vorliegt
------------------
Kurze Einführung:

a)
------------------------- langweiliges Zeug? lies bei b) weiter! ------
Wenn zwei BTClients Dateien tauschen dann findet es in etwa so ab.

Client(A) teilt Client(B) mit dass er ein bestimmtes Teil der Datei besitzt (Announce havePiece).
Die Mitteilung wird über die Tunnel mit verschieden Zwischenstationen (Participating) übertragen.

Client(B) erhält die Mitteilung und trägt sie in eine Liste ein (Client(A) hasPiece).
Ein Routine bei Client(B) überprüft ob man das Teil schon selbst besitzt oder nicht und es gegebenenfalls von Client(A) anfordert.

Besitzt Client(B) dieses Teil nicht sendet es eine Anfrage an Cient(A) über die Tunnel und Zwischenstationen und bittet um Zusendung des Teils (Request Piece).

Client(A) erhält die Anfrage von Client(B) und entscheidet nun ob alle Umstände gegeben sind dieses Teil an Client(B) zusenden oder dem Client Mitzuteilen das es momentan nicht geht (Choke Client(B)).

Im Falle einer positven Überprüfung wird das Teil nun endlich von Client(A) an Client(B) über die Tunnel und Zwischenstationen an Client(B) gesendet. geschickt.

b)
---------------------------
Dieser Vorgang wiederholt sich ständig zwischen allen Clienten eines P2P-Schwarms.

Hierbei entstehen grosse Wartezeiten und somit Lücken zwischen den Übertragungen, diese Lücken werden um so grösser je mehr ein einzelner Client zu verarbeiten hat und unter welchen Systembedingungen er arbeitet. Anzahl der Torrents, Anzahl der verbundenen Clients (Peers), CPU, real Ram, virtual Ram, Java allocated Ram, Festplatten Zugriffe, und, und, und ...

Ein Client kann auch mehr Anfragen für Teile gleichzeitig stellen, das spielt für die tatsächliche später Geschwindigkeit aber fast keine Rolle da die Teile serial, also nacheinander und nicht paralel, also gleichzeitig übertragen werden.

Möchte man nun eine gleichzeitige Übertragung von verschiedene Anfragen und Teilen erreichen, müsste man den bestehenden Code der Software sehr aufwendig verändern. zb. müsste in Snark der "Snarkmanager" zweimal gestartet werden, ebenso der Peermanager, aber es darf nur ein "Storage" (File/Diskmanager) laufen. Dies wurde zu grossen Problemen und Aufblähung des Codes führen, neben der sog. "Threadsicherheit" müsste auch ein Aushandeln zwischen den Datei und Disk Zugriffen stattfinden, mehrere Destination und/oder ClientID's müssen verwalten und überwacht werden . Alle in allem würde dies zu einem erheblichem Aufwand und grosser Fehleranfälligkeit führen.

Um die bestehende Bandbreite des Internetzugangs bzw. die die man an I2P vergeben hat voll auszunutzen und um die "Löcher" während der obigen Vorgänge zu füllen, ist es einfacher mehrere BTClienten gleichzeitig zu betreiben. Dies macht in soweit Sinn da die "Snark" basierenden Clienten im Ruhezustand nur sehr wenig Speicher und CPU Zeit benötigen. Alles das was sie unter Last mehr benötigen entspricht in etwa dem was ein angepasster, veränderter Client (siehe oben) ebenfalls benötigen würde.

c)
-------------------------------
Der Nachteil mehrerer Clienten ist, dass man natürlich für jeden dann auch einen eigenen Datastore benötiget und die Dateien jeweils darin als Kopien anlegen muss. Bei kleinen Dateien bis 700mb mag dies noch kein Problem darstellen, aber bei Dateigrössen von 7GB und mehr wird es schwierig. Nicht nur die Erzeugung der Kopien benötigt seine jeweilige Zeit, sondern auch die anschliessende Überprüfung der Dateien durch den Client, ganz zu Schweigen vom benötigtem Plattenplatz.


Dieser Nachteil ist nun durch den "Seed Swarm Service" der nun in xl integriert wurde entfallen.
Die Dateien werden nur einmal benötigt und eine Überprüfung der Dateien wird nur von einem Clienten des "Seed Swarms" ausgeführt.

d)
------------------------------------------
Wann sollte man eine Seed Swarm benutzen?

Sinn macht es wenn man:
- nur wenig Leecher im Torrent hat. ( kleiner 5 )
- der Torrent sehr gross ist.
- Superseed benutzt und möglichst schnell 100% der Teile des Torrents im Swarm verteilen möchte.
- man mehr als 100 kb/s ins Netzwerk übertragen kann.

Einige Zahlen:

1 - 5 Leecher .-> Seed Swarm Grösse 4 - 1
5 - 15 Leecher -> Seed Swarm Grösse 3 - 1
15 + Leecher ..-> Seed Swarm Grösse 2 - 1

- incomplete -

f
--------------------------
Vieleicht noch ein paar nützliche Hinweise!

Bei den Tests hat sich gezeigt dass es von Vorteil ist die Tunnlanzahl pro Client
Exclamation zu begrenzen Exclamation ,
dies steht im Gegensatz zu vorherigen Erfahrungen mit nur einem Clienten oder zwei.

Je mehr Clienten am Seed Swarm beteiligt sind, umso weniger Tunnel sollten die einzelnen Clienten haben!

Bei mir haben sich bei 2 - 5 Seed Swarm Units eine Tunnelzahl von jeweils 2 InBound und 2 Outbound und 0 Backup Tunnels bewährt, sogar ein setting von nur 1 In und 1 Out pro Client schien keine Nachteile bei einem Seed Swarm von 4 - 5 Units zu haben und sorgte für mehr als befriedigende Ergebnisse!

Alle tests sind natürlich mit mindestns 2 hops ausgeführt!

f
-----------------------------------------------------------------
Ich will nochmal an einem Beispiel zum besserem Verständnis erklären was hier passiert, bzw wie es funktioniert.

Nehmen wir mal an ich möchte mit einem Clienten ein File hochladen mit einer Grösse von 350mb und gehen davon aus dass sich 5 Leecher einfinden die das File herunter laden und ich sonst kein File im share habe.
Für das Beispiel setze ich die Participanten die meinen Rechner nutzen im Kopf auf 0!

Erfahrungswerte zeigen dass das File in etwa 1-2 Tagen von den ersten Leechern vervollständigt wird. Schaut man sich dann die Grafik von in- und outgoing an, sieht man dass das File in etwa mit 20 - 60 kb/s hochgeladen wurde. Wobei es mehr zu 20kb/s tendiert. Man könnte also sagen wenn ich 5 Files a 350mb hochladen will dauert es 10 - 20 Tage. Das stimmt so nicht!

Nimmt man nämlich alle 5 Files und und packt sie in den Upload, stellt seine Tunnel auf 5 in und 5 out und alle 5 Leecher sind in allen 5 Torrents anwesend , wird man in der Regel alle 5 Torrents in ebenfalls 1 - 2 Tagen hochladen.

Man hat hier zu den gleichen 5 Leechern 5 mal eine Verbindung mit den selben Destinationen gehabt. Der Unterschied zum erkennen und Verwaltung der Leecher entsteht anhand der 5 unterschiedlichen Torrents. Man füllt die Lücken der Übertragung indem man die Anzahl der Torrents erhöht ( Seeder seitig ).

Man kann dies umgekehrt nutzen indem man nun nicht die Torrentzahl erhöht um die Lücken zu füllen, sondern benutzt mehrere Clienten auf Seeder Seite. Hier baut man nun nicht mit einem Clienten und 5 Torrents zu 5 Leechern = 25 Verbindungen auf, sondern mit 5 Clienten zu 5 Leechern 1 Verbindung, dies sind ebenfalls 25 Verbindungen. Somit kann man in den 1 - 2 Tagen in etwa die gleiche Menge an Daten mit nur einem Torrent verteilen wie zuvor mit 5 Torrents und einem Clienten.

Das ist im Grunde das vereinfachte Prinzip das dahinter steckt.

-Ausnahmen bestätigen allerdings auch hier die Regel-

f
----------------------------------------------

http://forum.i2p/viewtopic.php?t=4570
##################################################################################

##################################################################################
version 20100524a

- including a Auto Limiter for superseedmodus
"AL" stays for "Auto Limiter". Don't call it "Anti Leech".
"AL" regulating the upload amount by the performence of the connected clients.
briefing: "Who spend much get much!" 
------------------------------------
swarmspeed and average of swarmspeed rising up, nobody get lost and even the lowliners get more from the swarm itself than normaly!
the parts of the firstseeds are in the right hands now! 

the line stays cool and the Ratio of i2p itselfs is untouched like with less files and peers!
it doesn't hurt anymore to use some more firstseeds at same time. CPU and Ram also looking better! 

-  "AL" detecting Powerleecher with multiclients
 Powerleecher with multiclients would be treated as one client - if they have a good performence they got same upload-amount like good performed single clients 

superseed with "AL" is the default setting now. switching OFF "AL" is only in the "Postman"-theme included, yet.
usage:
 * add torrent
 * switch on superseed
 * click "reset" to fill the pieceslist for uploading with all torrent pieces
 * hint: effectivest "piece length" for "AL" is 256kb
 

- adding the total values to the "Postman"-theme-
- some performence improvments
- enhanced choking control
...

my time is limited for developing xl and it takes to long that people testing the new updates.
When i'm coding on xl i have at least only a few days free time. it is unproductive to spend that time with waiting for your non-reaction of the new features and outstanding bug-reports.

this is proberly the last update for a longer term again. I try to commit one update with neccessary fixes (if there any) at june.
so, please report any trouble. enhancments are more effective with a engaged userbase but this seems not to be nowadays.
... and please, if you report a possible bug than reanswer on my help-postings if you had resolve the problem, whether or not! announcing a problem on your side and ignoring my requests are not very helpful and ungracious!

- next todo is to include a timeshift interval for older torrents it would be helpful too if the owners of i2p-trackers including a "scrape" function to their sites. thanks

#####################################################################################
Related postings!

AL - Auto Limiter <-> Ratio Control
------------------------------------
superseed modus with the new performence checker "AL".
"AL" stays for "Auto Limiter". Don't call it "Anti Leech".
"AL" regulating the upload amount by the performence of the connected clients.
briefing: "Who spend much get much!" 
------------------------------------
swarmspeed and average of swarmspeed rising up, nobody get lost and even the lowliner get more from the swarm itself than normaly!
the parts of the firstseeds are in the right hands now! 
--
my line stays cool and the Ratio of i2p itselfs is untouched like with less files and peers!
it doesn't hurt anymore to use some more firstseeds at same time. CPU and Ram even looks better! 
------------------------------------
##############################
 	Ratio ... think of it!

in a closed swarm with absolut fair share and 1 seeder the values are

ratio 0.50 - 2 Leecher
ratio 0.66 - 3 Leecher ~
ratio 0.75 - 4 Leecher
ratio 0.80 - 5 Leecher
ratio 0.83 - 6 Leecher
ratio 0.85 - 7 Leecher
ratio 0.87 - 8 Leecher ~
ratio 0.89 - 9 Leecher ~
ratio 0.9 - 10 Leecher

i mixed somethingelse up i've done yesterday ..

but the rest of my conclusion stay untouched by this. with everything some one else give more than for those with the smallest line it 's not more possible to come close a 'good looking' ratio. only the unique parts that they got from the seeder itself they may commit at the end!

so go away of deep ratio thinking and stop bashing on badly looking ratio. they might haven't a chance to find free space to put their parts in.
afterwards they proberly fulfill their duty who knows.
the real problems are the "jumpers" and those that running throw the swarms and youself howlong your are not care about your own ratio control. than you support this bad leeching behaviour.

- bs
----------------------------------------
ich hab das nicht grundlos hier reingeschrieben. Ich les im moment immer mehr postings mit dem hintergrund des schlechten ratio's. da wird gekickt, gebannt, private tracker gefordert, "erzieherische" torrents eingestellt mit dem upload eines teils pro stunde und und und. wobei letztere einen riesen müll und overhead erzeugen und alle paralelen torrents geschwächt werden, die tunnels unnötig aufrecht erhalten werden, und im ende das gesamte netzwerk ausgebremst wird. das alles nur weil irgendwer sein ego aufrecht erhalten will. blockwart- und oberlehrer- verhalten eben. wobei sich niemand über die hintergründe gedanken macht. ich hoffe dass mit obigen posting etwas bewegung in die köpfe kommt und mehr leute darüber nachdenken.

an die devs von btclienten, wichtig wäre die routinen für das nächste get-next-random-piece zu verbessern und gezielter nach dem "most missed piece" zu fragen oder wie immer man das nennen mag, damit es nicht dazu kommt das zum schluss alle auf einen warten müssen der die teile eigentlich schon von anfang an besaß und bloss vorher noch nicht danach gefragt wurde.

einmal ein leecher, immer ein leecher Wink

wir brauchen keine privaten tracker, wir brauchen mehr opentracker!
- bs

------------
weniger ist manchmal mehr, dies gilt besonders für tunnel bei multiclients!
achtet darauf die tunnelanzahl runter zuschrauben, 1 tunnel in und out ist genug bei einem torrent oder bei einer peer anzahl kleiner 15!
Back to top
	
----------------------------------------------
	
devzero wrote:
Blacksmith, that is very interesting to know. Thank you very much. How did you calculate this.?



(((count leecher * 100) - (1 * 100)) / count leecher) / 100
.....................................^________________________________<-seeder-upload
----------------------------------------------


http://forum.i2p/viewtopic.php?t=4579