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