Jednoduchý generátor všetkých IPv4 adries

7.1.2012 08:30 | Přečteno: 2318× | 3 | poslední úprava: 7.1.2012 08:22

Na úvod - kedže je to prvý môj zápisok v roku 2012 - všetko dobré do nového roku . Zaujímalo ma (po jednej siahodlhej debate na tému ipv4 vs ipv6 vs DNS) akú veľkosť by mal súbor obsahujúci v každom riadku presne jednu IPv4 adresu (začínajúc od nezmyslu 0.0.0.0 až po nezmysel 255.255.255.255 čiže 2^32 alebo 4 294 967 296 možných unikátnych adries). A ako dlho jeho vytvorenie bude trvať. Takže tu sú moje výsledky.

Testovacia zostava - Compaq nc6320, C2D T5500, 2MB cache, 1,5GB RAM, SSD 32GB, Debian 6 i386. Napísal som si jednoduchý programček v Pascale.

var aaa,bbb,ccc,ddd : integer;

begin
 for aaa:=0 to 255 do for bbb:=0 to 255 do for ccc:=0 to 255 do for ddd:=0 to 255 do writeln(aaa,'.',bbb,'.',ccc,'.',ddd);
end.

Ten som následne preložil a spustil:

time ./ipv4_adds > ipv4.txt

Čo chvíľu trvalo... A skončilo sa to neúspešne, nakoľko /home má na notebookovskom SSD iba 21GB a teda skončil som na hláške "No space left on device". Takže nasledovalo pripojenie 250GB disku skrz USB a opätovné spustenie. Vytvorenie súboru trvalo:

real	44m18.968s
user	27m18.690s
sys	13m41.483s

Veľkosť súboru:

$ du ipv4.txt 
59899904	ipv4.txt
$ du -h ipv4.txt
58G	ipv4.txt

Nejaké ďalšie štatistiky:

$ time wc ipv4.txt 
 4294967296  4294967296 61337501696 ipv4.txt

real	48m28.705s
user	46m46.351s
sys	1m21.309s

Čo poviete? Zaujimavé nie?

       

Komentáře

[brk]

Ten tvůj soubor by se mohl hodit. ;o) Když už jsi to vygeneroval, nahraj to ještě třeba na ulož.to, nebo raději na více podobných serverů, ať to nemusí ostatní generovat znovu. A hlavně to nekomprimuj, to by byla zase zdlouhavá dekomprimace a pozbylo by to smysl. ;o)

[Michal Fecko]

58GB na uloz.to?

[hlasovani]

Radši torrent.

[Radovan]

Poslat mailem, stáhnu si to na disketu. Nebo že bych to zkusil v TurboPascalu pod DOSBoxem?

[zxtlpn]

Ty jsi debil, ne? :D Nenapadá mě případ, kdy by nebylo rychlejší a smysluplnější to vygenerovat.

[=^..^= AmigaPower®]

Než začneš označovat lidi za debily, chtělo by se to zamyslet jestli se třeba nejedná o ironii, ono to dost bije do očí i bez těch prapodivnejch smajlíků, smysl mít xGB soubor s čísílkama 0.0.0.0 - 255.255.255.255 je totiž dost dobře nepochopitelnej, pokud se teda zrovna nechci chlubit blondýnkám že mam doma všechny IP adresy

[zxtlpn]

Já už bych věřil lecčemu.

[xkucf03]

Nevím, jak máš rychlé připojení, ale tohle přece dřív vygeneruješ, než stáhneš.

[brk]

Samozřejmě, ale na co by mi ten soubor tak asi byl? Kdybych už něco takového potřeboval, tak si raději přečtu něco třeba o fuse a generuji si ten soubor "za letu".

Taková kravina byla samozřejmě myšlena ironicky, jak již výše okomentoval =^..^= AmigaPower®.

[Dreit]

Ha, díky za nápad - dala by se na tom testovat rychlost komprimace/dekomprimace. Rozhodně jestli se mi to povede vygenerovat, tak zkusim LZMA kompresi a někam to uploadnout. Zatim jsem "jen" na 39.113.249.255

[Roger]

Protože neumím programovat, zkusil jsem si to aspoň spočítat.

Soubor v linuxu bude mít 17179869184*3,5703125-1 = 61337501695 bytů a jeho zápis na externí USB 2.0 disk zabere minimálně 17 minut (prakticky to bude tak dvakrát déle).

Co jsem vyhrál? :)

[=^..^= AmigaPower®]

Pobyt na klinice Mr. Jílka

[Radovan]

Proč to -1? Poslední řádek nebude ukončený \n? A kdyby Windows, tak jsou to ještě čtyři giga navrch

[Roger]

Přesně tak, v zadání se píše: "súbor obsahujúci v každom riadku presne jednu IPv4 adresu." Tedy adresy jsou odřádkováním odděleny, ne ukončeny, jinak by poslední (prázdný) řádek nesplňoval požadavky.

A ano, proto jsem psal "v linuxu".

[Radovan]

Nojo, ale má tam writeln

Narazil jsem už na pár programů, které neukončený poslední řádek považovaly za chybný, nebo ho ani nedokázaly načíst...

[kralyk z abclinuxu]

Afaik v Linuxu / UNIXu taknějak všeobecně patří k dobrému bontonu nechávat na konci textových souborů jedno '\n'.

[GeoRW]

jj, nejake nixy potom zle pocitaju pocet riadkov wc -l

[:::]

jinak by poslední (prázdný) řádek nesplňoval požadavky

to zalezi jestli newline character povazujes za oddelovac nebo ukoncovac radku. Pokud za ukoncovac tak tam prazdny radek neni, i kdyz ho nektery editory zobrazi...

There is also some confusion whether newlines terminate or separate lines. If a newline is considered a separator, there will be no newline after the last line of a file. The general convention on most systems is to add a newline even after the last line, i.e. to treat newline as a line terminator. Some programs have problems processing the last line of a file if it is not newline terminated. Conversely, programs that expect newline to be used as a separator will interpret a final newline as starting a new (empty) line.

zdroj: http://en.wikipedia.org/wiki/Newline

[pavlix]

Po pěti minutách práce s různými unixovskými příkazy (tip: zkus cat, tail a podobné), zjistíš, že NL je line terminator, ukončovač řádků, a že tedy patří na konec každého řádku textového souboru. Stejnětak zjistíš, že UTF-x BOM je chyba, UTF-8 BOM navíc zbytečná chyba.

Na jiném OS můžou být jiné zvyklosti, ale i tak je tohle obecne nejrozumnější možný přístup. Společně s tím, že ukončovač řádku je jednoznakový.

[tom]

Napriklad v C je neprazdny soubor, ktery neni ukoncen znakem noveho radku, povazovan za syntakticky chybny. Nektere prekladace takovy radek ignorovaly.

Nekdy se tomu znaku rika EOL (z end of line), takze jejich pocet pak odpovida presne poctu radku.

[Martin Mareš]

Jenže alespoň v unixové tradici \n není oddělovač, nýbrž ukončovač řádku.

[Radovan]

A podle tradice musí být každý řádek ukončený, jinak neexistuje.

Také by se to dalo říct tak, že každá položka v souboru je oddělená ukončením řádku

[pavlix]

Také by se to dalo říct tak, že každá položka v souboru je oddělená ukončením řádku

Říct se to sice dá, dokonce i napsat, po striktní logice dokonce dojdeš k tomu, že je to pravdivý výrok (pokud je každá položka na samostatném řádku), ale přesto je nesmysl se podle toho řídit.

[Radovan]

Takže u výpisu mám mít ještě jedno if(), abych odlišil neodřádkovaný poslední řádek od všech ostatních? Tímhle způsobem by mi ten program po pár takových "vylepšeních" neběžel tři hodiny ale tři dny

Ano, řádky mají být odddělené, takže poslední řádek je oddělený od konce souboru.

[xkucf03]

Ten if je zbytečný – když máš metodu/funkci načtiDalšíŘádek(), tak v ní prostě čteš vstup, dokud nenarazíš na konec řádku nebo* souboru a načtenou hodnotu vrátíš. Takže z tohoto pohledu (načítání souboru, kde položka = řádek) je úplně jedno, jestli tam to poslední \n je nebo ne. (význam to má akorát při spojování souborů nebo při výpisu do konsole…)

*) je jasné, že za koncem souboru už řádek nepokračuje, takže vrátíme hodnotu. Kdybychom chtěli být zlí, tak vyhodíme výjimku, že je řádek v neplatné syntaxi (není ukončen \n), ale to by asi k ničemu dobré nebylo.

[Bedňa]

Máte veľa miesta na disku? Tu je náš skript z WS teleschopu čo vám s tým pomôže Zaujímalo by ma ako na tom bola ramka počas vytvárania súboru.

[Johny z Podoli]

nechceš zkusit i tohle? v C? ... jen to asi bude házet chyby, chce to poladit od někoho kdo v C programuje já moc ne.
Hooodně mě totiž zajímá, jak rychlé by to bylo oproti tomu tvému

	unsigned long i;
	for (i=0; i<2^32; i++) {
	sprintf("%i.%i.%i.%i",(*i & 0xff000000)>>24,(*i & 0x00ff0000)>>16,(*i & 0x0000ff00)>>8,(*i & 0x000000ff));
	}

[loki]

Obavam se, ze operator ^ nedela to, co si myslite XOR

[Tom]

Dneska ty lidi neumeji ani spravne zavolat printf, natoz pak sprintf.

[Tom]

A ani neumi zapsat unsigned konstantu a predpokladaji velikost datovych typu, ach jo.

uint32_t i = UINT32_C(0xffeeffee);
printf("%" PRIu32 "\n", i);

[Johny z Podoli]

nejsem programátor v C tohle jsem někde našel a upravil, snažil jsem se to pochopit... mé znalosti končí u PHP, čímž jsem značně deformován

[TurboLama]

Spíš nějak takhle:

#include <stdint.h>
#include <stdio.h>

int main()
{
    uint32_t ip = 0;

    do
    {
        printf("%u.%u.%u.%u\n", (uint8_t)(ip >> 24), (uint8_t)(ip >> 16), (uint8_t)(ip >> 8), (uint8_t)ip);
    }
    while (++ip <= 0xffffffff);
}

Ale nemám dost místa na disku na to abych to odzkoušel

[zxtlpn]

Nejefektivnější by bylo nejdřív vygenerovat tabulku řetězců pro všechna čísla od 0 do 255, printf() má taky nějakou tu režii. Takhle by stačilo např. puts().

[oooooooooooooooo]

Tak nejak to mam, akurat puts() ma tiez nejaku reziu, tak pouzivam putchar. Moj cas pri vystupe do /dev/null: real 14m1.998s user 13m58.024s sys 0m2.884s

[poky74]

Určitě je to správně? Gynerovaný soubor má už 63GB a pořát jede, zdá se, odzačátku .. :D

[poky74]

poky@antik:~$ time ./c > ips

Ukončen (SIGTERM)

real 28m31.981s

user 25m41.980s

sys 1m38.766s

poky@antik:~$ du ips

69162400 ips

poky@antik:~$ du -h ips

66G ips

poky@antik:~$ wc -l ips

4998991943 ips

poky@antik:~$

Taky jsem si ten kód mohl nejdřív pořádně pročíst...

[TurboLama]

Jasně, ta podmínka je samozřejmě blbost - vždycky true.

[Radovan]

Já jsem to zkusil takhle:

int main(void)
    {
    int i,j,k,l;
    long long int x=0;
    char ip[20];

    for (i=0;i<POCET;++i)
       {
       printf("%03d\n",i);
       for (j=0;j<POCET;++j)
           for (k=0;k<POCET;++k)
               for (l=0;l<POCET;++l)
                   {
                   sprintf(ip,"%d.%d.%d.%d\n",i,j,k,l);
                   x+=strlen(ip);
                   }
       }

    printf("%lld\n",x);

    return 0;
    }

O ukládání do souboru jsem se ani nepokoušel, nejvíc místa na jednom disku mám gigabajt. I takhle ten program trval rovné tři hodiny

[poky74]

A kde je test ipv6?

[=^..^= AmigaPower®]

Zdar, mám v jednání kvalitní bavlněný trika (né sračky typu Fruit Of The Loom) od cca 9 Kč (+ clo) a pola (Made in UK) od cca 40 Kč, kdyžtak dej vědět (ale odběr ks. je mazec).

PS: výplety mám taky v jednání, podle počtu kusů buď rovnou v UK (jen ty pola), nebo v PL.

[AsciiWolf]

A proč to píšeš zde?

[=^..^= AmigaPower®]

A proč ne?

[Bystroushaak]

Protože abclinuxu chybí webforum.

[AsciiWolf]

No, konkrétně tohle (a podobné "osobní záležitosti") je vhodné řešit spíše přes e-mail či IM, než s tím spamovat nějaké fórum.

[Bystroushaak]

Jenže je to něco, co by zároveň pravděpodobně mohl chtít i někdo jiný. Taky se chtěl třeba pochlubit formou otevřeného dopisu :)

[=^..^= AmigaPower®]

Ty jsi kluk, jako buk! ...tak je pochopitelně jasný, že pro kernelultras.org je 1000+ triček kapku moc...

[Michal Fecko]

Nedá sa ;)

[SKooDA]

Je to divný, ať počítám, jak počítám .. nějak se nemůžu dopočítat :( počet IPV4 adres (včetně dedikovaných prostorů pro intranet atd.) je 10^12=1000000000000 každá adresa zabírá 12bitů, takže celkově se dostáváme k 12000000000000b (/1024) = 11718750000Kib (/1024) = 11444091,8Mib (/1024) = 11175,9 Gib což je asi 11Tb .. i kdyby jsi to ukládal bez teček mezi trojicemi čísel, takže naprosto nechápu jak je možné že se ti to vešlo na externi HDD.

Počítám něco špatně?

[poky74]

Počet ipv4 adres vám trochu hapruje, 10^12 jste vzal kde? Je to snad 2^32 ne? Tedy 4 294 967 296 adres..

[SKooDA]

Jj .. už vydím kde jsem udělal chybu :( děkuji .. předpokládal jsem adresy které nemohou existovat, jako např.: 858.585.566.666

[mess]

Vydím? UAAAAAAAAAAAAAAAAAAAAAAAAAAA!

[SKooDA]

Ještě dodám že předpoklad je ukládání v ASCII a vynechávání teček (Pokud vím autor ukládá nejspíše v UTF8 a tečky tam má, takže výsledný soubor by měl být ještě o dost větší)

[Roger]

UTF8 je irelevantní, protože u čísel vypadá stejně jako ASCII.

[pavlix]

Ty znáš nějaký ASCII znak, který se v UTF-8 kóduje jinak než v ASCII? Já ne. (Nápověda: základní vlastnost UTF-8)

[h0nzZik]

Kde jsi vzal ty šílený čísla? Každá adresa zabírá 4 bajty, tedy 32 bitů, to máme 2^32 kombinací. Tvých 10^12 je o dva řády víc. Tvých 12 "bitů" je ve skutečnosti 12 desítkových míst. Ale spočítat se to samozřejmě dá. Pokud budeme mít zápis:

X.X.X.X

(a enter), tak se nám záznam skládá pokaždé ze 4 fixních znaků (3 tečky a enter). Každé X může nabývat hodnot 0..255, což je 10 jednociferných čísel, 90 dvojciferných a 156 trojciferných. Průměrný počet cifer jednoho takového X je tedy:

(10+2*90+3*156)/256 = 658/256 = 329/128 = 2.57

Kvůli přesnosti to necháme ve zlomku. Průměrná velikost jednoho záznamu jsou tedy:

4+4*329/128 = 4+329/32 = 457/32 = 14.28

No a máme celkem 2^32 kombinací, takže velikost souboru je:

2^32*457/32 = 2^(32-5)*457=2^27*457=61'337'501'696

bajtů, což je přibližně 57 gigabajtů. Srovnáme-li si čísla se zápiskem výše, uvidíme, že na bajt souhlasí ;)

[Ivorne]

No ono se to dá pojmout ještě jednodušeji. Máme 4 čísla (X.X.X.X), kde každé z čísel může nabývat 255 různých možností. Takže dohromady tu je 255*255*255*255 možných adres.

Taky důležitá věc, kterou si někteří neuvědomují je, že ipv4 adresa je jedno jediné celé číslo uložené do 4 bytů (tedy 2^(4*8) možností). Ten zápis 255.255.255.255 je jen přepis jednotlivých bajtů na desítková čísla. Například u ipv6 se používá přepis do hexadecimálního čísla. Tedy každý bajt se převede na 2 šestnáctkové číslice. Ipv6 btw používá 16 bajtů. Takže to je 16*8 bitů, což je 2^(16*8) adres. Ale i ipv6 se dá zapsat jako 16 čísel od 0 do 255.

[Michal Kubeček]

Máme 4 čísla (X.X.X.X), kde každé z čísel může nabývat 255 různých možností.

256

[h0nzZik]

Prave ze neda. Protoze adresa muze byt treba:

1.2.3.4

ale taky

10.0.128.240

nebo

196.168.0.1

cize ma promenlivou delku. Samozrejme v sestnackovy soustave by to bylo jednodussi, treba:

AB.CD.EF.51

ale i tak by mohly existovat adresy:

10.A.1B.1

s ruznou delkou.

[vencour]

Podle masky sítě může být i 11.22.33.0/8. Ale zpravidla se toto nepoužívá.

[Heron]

akú veľkosť by mal súbor obsahujúci v každom riadku presne jednu IPv4 adresu

IPv4 adresa je 32b číslo, tedy 4B. 2^32*4B = 16 GiB. Použijeme-li nějaký znak jako oddělovač tak to bude 20GiB. Netřeba generovat a hlavně netřeba ukládat. Btw. jsi to mohl prohnat přes pv do /dev/null.

[Michal Fecko]

IPv4 adresa je 32b číslo, tedy 4B. 2^32*4B = 16 GiB.

To mi bolo jasné pred testom - nebolo mi jasné akú veľkosť by mal ASCI súbor. Ešte by som chcel odfiltrovať _nejako_ (???) len adresné rozsahy patriace SR a CR z tohto zoznamu, takže hádzať to do /dev/null pre mňa nemá nejako význam :)

[Michal Kubeček]

To mi bolo jasné pred testom - nebolo mi jasné akú veľkosť by mal ASCI súbor.

Nicméně počítat to tak, že si je všechny vygenerujete, je nesmysl (a když už, je nesmysl si ten soubor generovat na disku a pak na něj pouštět wc, od toho máme roury). Stačí jednoduchá úvaha: každý byte může nabývat 10 jednociferných, 90 dvouciferných a 156 tříciferných hodnot, každá se ve výpisu zopakuje 2^24-krát (pro všechny kombinace zbývajících tří). K tomu navíc na každý řádek připadají tři tečky a jeden linefeed. Celkem tedy 4*2^24*(10+2*90+3*156) + (3+1)*2^32 = 61337501696. I kdybych to počítal ručně pomocí tužky a papíru, budu o řád rychlejší než váš program…

[pc2005]

Imho +1, cvičení z kombinatoriky.

Nicméně metoda brutalforce je aspoň zvedla náladu .

[pc2005]

mi*

[Bedňa]

Ešte by som chcel odfiltrovať _nejako_ (???) len adresné rozsahy patriace SR a CR z tohto zoznamu

To sa stále mení

[Michal Kubeček]

Především by bylo potřeba nejdřív definovat, co to "patriace SR a CR" vlastně znamená…

[JS]

No, ale ruzne specialni adresy by vyfiltrovat mohl.. I kdyz asi by to nebylo o moc tezsi spocitat v ruce.

[vencour]

Nestačilo by jen definovat přes regulární výraz třeba formu IP adresy a pak podle potřeby s tím pracovat? Z toho bys mohl i spočítat velikost souboru ... místo samotného generování.

[qw11]

Jee ja sa prave hrajem s generovanim kombinacii pre LOTO. Ale iba kombinacii ktore sa daju realne zapisat na tiket. Nepocital uz niekto aj toto? Kolko asi toho bude.(kombinacii a GB) :D

[Bedňa]

Nemal si žmurkať, keď ste sa v škole učili o faktoriáloch.

[qw11]

No tak to som asi nezmurkal ale chrapal ako sa dalo. :D

[Michal Fecko]

Myslel som ze sa to robi tak ze sa dlhodobo sleduju a zapisuju vyherne cisla a tie ktore sa najviac vyskytuju sluzia na tvorenie takychto kombinacii. Alebo ako?

[qw11]

To ano statisticky sa zistia najcastejsie zrebovane cisla. Ovsem tu islo o to ze v praci sme sa bavili kolko je asi kombinacii ktore sa daju realne zapisat na tiket bez toho aby boli dva tikety s rovnakymi cislami. No a ani ty co to preberali v skole uz neboli schopny zistit ako to vypocitat no a na generovanie to vyzera tiez na par tyzdnov. :D aspon podla toho co sa mi podarilo zlepit(neviem programovat).

[Radovan]

Nechce se mi hledat jak se sází Lotto, ale ve Sportce se zaškrtávalo 6 čísel ze 49, takže:

 49*48*47*46*45*44
------------------- = 13983816 sloupečků
    1*2*3*4*5*6

A samozřejmě to musíš vydělit počtem sloupečků na tiketu (ani nevím kolik jich dneska je), vyjde ti počet tiketů...

[qw11]

Tak to som cakal viac.

[SPM]

No, 1:14M, to je asi stejně pravděpodobný, jako že mě sundá meteorit, když vyjdu před barák :)

[kotyz]

Už se to pár lidem stalo, tak jen to nepřivolávej ...

[Jendа]

Jako že skoro každý den srazí jednoho člověka v ČR meteorit?

[=^..^= AmigaPower®]

Já včera cestou z hospody schytal hned čtyry...

[SPM]

Nevšim jsem si, že by skoro každý den někdo vyhrál sportku - tedy vyhrál - uhodl všech 6 čísel, ne jenom část.

[:::]

o sportce nic nevim, ale kdyby se losovala 1x denne, a hralo vsech 10e6 obyvatel CR, a pravdepodobnost vyhry byla 1/14e6 tak by vyhral prumerne 1 clovek za 1.4 dne.

vsechny ty podminky ale splneny nejsou takze to bude min casto...

Potom k vete

No, 1:14M, to je asi stejně pravděpodobný, jako že mě sundá meteorit, když vyjdu před barák :)

pokud to mam interpretovat jako P(sunda me meteorit | vyjdu pred barak) = 1/14e6, tak pri 10e6 lidech, kazdy vyjde pred barak prumerne 2x denne (jenom odhad), by meteorit sundal prumerne 2*10e6 / 14e6 = 1.43 lidi denne.

[SPM]

Tak já třeba včera nevylez ani jednou :)) ale jo, možná je to trochu přestřelený, ale ta pravděpodobnost je mrzká... ikdyž se dostaneme k tomu, že to jednou za 14 dní někdo vyhraje, tak pro mě je to furt smůla - já mám tu šanci pořád něco jako 1:14M, takže bych musel nasázet 14M tahů, abych to vyhrál (nebo nějaké tomu podobné číslo, abych měl výrazně vyšší pravděpodobnost)...

[manasekp]

k cemu to je dobre? samozrejme ze to jde vygenerovat, jsou to jenom cisla ale nejak me neni jasne vyuziti takovych dat.

[pavlix]

Soubor pro nahlášení těch, kdo stahovali či nabízeli nelegální obsah? :)

[vencour]

Jooo VŠICHNI

[pc2005]

127.0.0.1/8 BTW všichni ne, někteří stahovali na IPv6 .

[manasekp]

tak to potom jo, uz jenom staci aby OSA podala 2^32 trestnich oznameni a casem az to nekdo zpracuje skoncime vsichni v kriminale :D

[SPM]

Třeba začnou u 127.0.0.1 a budem v pohodě ;)

[Yokotashi]

Nebylo by o trosku rychlejsi a mene narocne na diskovy prostor to vypsat do retezce, zjistit jeho delku, ulozit delku a retezec zapomenout?

Nebo to ani nevypisovat a jen spocitat delku retezce pro kazdou ctverici cisel?

A nebo vyjit z toho, ze 1mistnych cisel je 10, 2mistnych 90 a 3mistnych 156 a pouzit krome scitani i nasobeni?

2^24*(10+2*90+3*156)*4 + 3*2^32 + 2^32

prvni clen jsou cisla, druuhe tecky a posledni \n.

Uz chapu, proc vsichni potrebuji tak rychle pocitace a velke disky.

Yokotashi

chapadla.cz

[SPM]

Uz chapu, proc vsichni potrebuji tak rychle pocitace a velke disky.

To jako že u pornosbírky ti taky stačí si poznamenat, jak je velká a kolik je minut a obsah už mít nemusíš?

[pc2005]

To jsem někde četl, že nějaký lidi vzrušuje už jen sledování progress baru, během toho co si stahujou porno .

[pavlix]

Tebe ne? :D

[pc2005]

U lineárního stahování stačí -forceidx .

[kotyz]

To nejlepší je stejně až na konci ...

[SPM]

Tak teoreticky by to mělo jít - stáhnout hlavičku a konec souboru a přetočit to

[pc2005]

, nejvíc mě u videí štve .mp4, ten se nedá přehrát mplayerem, dokud není celý .

[pavlix]

forceidx je hack, který se používá jenom proto, že dotyčný přehrávač není schopný se s tím streamem vypořádat. A ani to moc nefunguje (vygeneruje index pouze pro staženou část, místo aby ho průběžně doplňoval, takže ve streamu později stejně nefunguje seek... a člověk by si občas rád kousek vrátil, že :))

[A]

ake pekne fajnsmekrovske vlakno....

[pc2005]

No ale pořád je imho ta doba strávená znovuspouštěním nižší než čekání na celé video.

[pavlix]

Zase je to takové nepohodlné... když máš staženo, tak už to jede bez přerušení.