Omezit pocet spojeni na UDP neni mozne, protoze UDP zadna spojeni nesestavuje - proste to veme a nesype to tam, pritom ho vubec nezajima, jestli druha strana je schopna data prijmout. Naopak TCP sestavuje spojeni tak, ze prida do TCP hlavicky priznak SYN a ceka na potvrzeni od druhe strany, proto je mozne kontrolovat pocet spojeni, ktere se pokousi navazat.
Na ty p2p site doporucuji ipp2p :
nj ale co sifrovany bittorent ? To je zrejme ten problem o ktorom sa tu bavime. Zatial to dokaze asi len NetEnforcer ale to je trochu ina cenova kategoria...
No ale on to umi, viz 8) To je prekvapko, co?
Jo a jeste vypis z Changelogu ipp2p:
# changes are: new (experimental) protocols: mute, xdcc(block only) and waste (THX to joco)
# detects BitComet header encryption
# edonkey udp bug fixed
# some new rules for winmx
# more code cleanup (the code does not look very well)
ipp2p pouzivam spolu s omezovanim rychlosti. Funguje jak ma, az na bittorenty. Pokud to zkousim na sobe, vzdy me to omezi jak ma. Obcas se ale najde nektery uzivatel, ktereho to neomezuje, nebo jen castecne (jedna se pouze o torrenty, ostatni p2p jsou vzdy ok) Bohuzel jsem neprisel na to, za jakych okolnosti se uzivateli (nebo spis nekteremu torrent klientovi, uzivatele vi prd) podari zkrz toto projit.
Mam ipp2p prelozeno primo do firmwaru pro rtl8186, takze muzu nahlizet do /proc/net/ip_conntrack pro toho konktretniho uzivatele, ktery ipp2p nejak obejde. V ip_conntrack jsou videt nektere neoznacene (mark=0) konexe, ktere urcite vyvolal onen torrent klient.
No proste abych to zakoncil, obcas ipp2p nejake spojeni neoznaci a to pak samozrejmne nejde zaradit mezi p2p. Na zadne reseni jsem neprisel. Akorat koukam obden na ipp2p.org, jestli neni nova verze :-)
Zdar