Autor: Jaroslaw Lis (lis_at_ict.pwr.wroc.pl)
Data: Sun 26 Jan 1997 - 16:29:05 MET
On 25 Jan 1997 20:06:40 +0100, Grego_at_RMnet.it (Gregorio Kus) wrote:
>pakiety nie gubia sie wskutek zaklocen prawie nigdy.
Gubia sie gubia. Im bardziej 'analogowa' transmisja tym wplyw zaklocen
wiekszy.
Na szczescie czesc 'analogowa' to tylko po telefonach i falach
radiowych.
> [znacznie czesciej zachodzi zjawisko odwrotne:
> dostaniesz kilka razy ten sam pakiet.]
Hm, Z kim Ty sie laczysz. Jeden ICM lubi odpowiedziec wielokrotnie,
a poza tym, to jesli dostajesz wielokrotnie te same pakiety, to tylko
z uwagi na mala przepustowosc.
>Pakiety po prostu "umieraja" (kazdy z nich ma w momencie startu
>zakodowany czas zycia - to zabezpiecza przed zapchaniem sieci
>bladzacymi pakietami).
To tez, ale normalnych transmisji to nie dotyczy. Zauwaz ze pakiet nie
jest "bladzacy", skoro ma prawidlowy adres, do ktorego inne pakiety
jakos jednak dochodza.
A 'czas zycia' jest podany w ilosciach routerow, a nie sekundach...
>dyby wszystkie lacza, routery i tak dalej
>mialy wieksza przepustowosc to pakiety nie ginelyby praktycznie
>nigdy.
No coz, bocianom zdarza sie chyba przeleciec czasem na antena do
satelity. Ale masz racje - wiekszosc ginacych pakietow to kwestia
miernej przepustowosci lacz ... i routerowi brakuje pamieci zeby
zapamietac przychodzacy pakiet, bo cala jest zajeta pakietami juz
czekajacymi na wyjscie..
>Ja czasami przepuszczam 20MB w ciagu jednego dnia przez ppp
>z efektem: 0 (slownie zero) pakietow blednych. A gdzie porownac
>modem/linie telefoniczna z ta technika, ktora idzie od mojego
>providera i dalej w swiat.
Moment - co tak naprawde mierzysz? Sprawdzasz statystyki modemu zeby
zobaczyc v42 retransmitted packets?
Bo wlasnie korekcja bledow w modemie gwarantuje Ci, ze trasmisja od
komputera do routera bedzie bezbledna.
Nie zdziw sie tez ze nie dostaniesz zadnego 'blednego' pakietu, w
sensie ze jest przeklamany i suma kontrolna sie nie zgadza.
Router takiego do Ciebie nie przysle, a modem nie przeklamie, to skad
sie maja brac :-)
Musialbys raczej sprawdzic w TCP ile pakietow musialo byc
retransmitowane.
>> Skutek jest taki, ze u celu czyli w moim komputerze program
>> obslugujacy TCP/IP musi zestawic z pakietow przychodzacych
>> w przypadkowej kolejnosci caly plik np. obrazek. Przy transmisji
>> skomplikowanej strony z kilkunastoma obrazkami taki TCP/IP
>> musi sledzic odtworzenie kilkunastu plikow zlozonych z kilku tysiecy
>> kawalkow.
>
>az tak zle nie ma, najprawdopodobniej te kawalki maja po 1.5kB
>wiec z kilkoma tysiacami to znow nie przesadzajmy :-)
Jest jescze lepiej - TCP nie wysyla calego pliku, tylko jego fragment,
o dlugosci 'TCP Window', ktore ma typowo jakies 4-8KB, daje zaledwie
kilka pakietow. Nastepne pakiety wysyla sie dopiero jak odbiorca
potwierdzi odbior choc jeden z wyslanych wczesniej pakietow.
Nawiasem mowiac - zmiana kolejnosci jest rzecza dosc rzadka...
>> Prawdziwi fachowcy (tzn. tacy, ktorzy wiedza ile jest w bajtow
>> w pakiecie oraz jaka jest struktura pakietu) moga mnie poprawic.
Ilosc bajtow w pakiecie jest po pierwsze zmienna, a po drugie moze sie
nawet po drodze zmianic. Warstwa IP zezwala urzadzeniu po drodze
"rozmienic" dlugi pakiet na kilka krotszych.
Dosc typowe dlugosci to 1.5 KB dla ethernetu, i 512B po modemach -
tu dopoki nie bylo korekcji bledow lepiej bylo slac krotsze pakiety.
>p.s. a propos dyskusji z P.Red. Wimmerem - implementacja TCP/IP
> jest zadaniem ogromnie zlozonym, znacznie bardziej zlozonym [...]
> Jest bardzo wiele momentow w diagramie decyzyjnym, ktorych
> definicje protokolow nie zalatwia. W dodatku decyzje te musza
> byc podejmowane dynamicznie, w zaleznosci od zmieniajacych sie
> warunkow na sieci (nie wystarcza w zadnym przypadku przyjecie
> jakichs stalych w rodzaju - szerokosc "okna" 100 pakietow,
> albo "jesli w ciagu 20 sek nie przychodzi ack to ponawiam".
Sporo z tych rzeczy jest ustandaryzowanych w RFC, i trzeba po prostu
przeczytac dokumentacje.
Odstepstwa od niej sa czasem nawet szkodliwe...
> Nic wiec dziwnego ze implementacja w wykonaniu
> M$ daje popalic - M$ nie ma ani wysokiej klasy programistow,
> a jezeli ktos z tym polemizuje, to w kazdym razie - to nie
> jest technologia ktora da sie szybko opanowac, a doswiadczenia
> w sieciowych s.o. to M$ zdecydowanie brakuje, z tym to sie
> chyba mozna zgodzic, nieprawdaz?
Doswiadczenia to ja bym im juz nie odmawial - ale FSM tez ma 30 lat w
robieniu samochodow i co z tego...
J.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Tue 18 May 2004 - 15:53:14 MET DST