nespolehlivy prenos pres netcat (DELSI)
oldfrog.linux na volny.cz
oldfrog.linux na volny.cz
Čtvrtek Září 23 12:38:16 CEST 2004
Tomáš Janoušek wrote:
>> read(net): Connection reset by peer
>>
>>
>Tusim ze by to mohlo mit neco spolecneho s tim ze vase sit je rychlejsi nez
>disky na clientovi. Netcat (stejne jako mnoho jeho klonu) se ukonci ihned co
>jakakoliv strana zavre spojeni (tzn. bud druha strana anebo EOF na stdinu).
>Stalo se tedy asi tohle: server mu tam vysypal cely soubor a nasledne hned
>ukoncil spojeni. Client to ukladal, ukladal a kdyz se server ukoncil tak se
>ukoncil taky. No a jelikoz nc pouziva neblokujici zapis (iirc), tak se to
>proste nezapsalo vsechno. Resenim tedy bude nejspis pouzit nejaky program,
>ktery tohle ma sam vyresene, anebo klon netcatu, ktery proste neblokujici
>zapis neumi :].
>
>S pozdravem,
>
>
> root na router # netcat -l -p 9998 -e "cat /tmp/orig.txt";
> root na client # nc router 9998 > recv.txt;
>
Dekuji za podnetnou myslenku. Pokousel jsem se zpomalit odesilani dat,
za cat
na odesilaci a posleze i na prijimaci strane jsem pridal jeste smycku,
ktera data
zpracovavala po radce nebo po znaku a vysledek je stejny - spojeni
resetovano.
K resetu dochazi v ruzny okamzik - prenese se nahodne ruzne velka cast
souboru,
vzdy ale se prenese alespon kolem 90% souboru. Stejne se to chova pri
prenosu
textovych i binarnich dat. Rad bych tomu prisel na kloub. Jak zjistim,
zda netcat
pouziva blokujici nebo neblokujici spojeni?
Dale jsem otestoval, ze ke stejne chybe dochazi i mezi dvema beznymi
distribucemi
(2 Slackware) a ze se tedy nejedna o chybu specifickou pro BusyBox nebo
uClibC.
Diky,
O.
--
------------------------------
Ondrej Nemecek alias 'OldFrog'
tel (domu): 241766035
tel (prace): 222090711
tel (mobil): 775046246
icq: 250163477
------------------------------
Další informace o konferenci Linux