Autor: Michal Letowski (milet_at_geocities.com)
Data: Sun 13 Aug 2000 - 10:48:01 MET DST
Uzytkownik "Michal Zalewski" <lcamtuf_at_dione.ids.pl> napisal w wiadomosci
news:Pine.LNX.4.21.0008122249110.13077-100000_at_dione.ids.pl...
> On Sat, 12 Aug 2000, Michal Zalewski wrote:
>
> > poprawnosci danych przeciskanych przez modem odpowiadaja protokoly
> > realizowane na poziomie sprzetu - wszystkie MNP itp (nie chce zmyslac
ani
> > szukac numerka w specyfikacji).
>
> A moze to nie MNP odpowiadala za sumy kontrolne i korekcja, nie wazne
> [zabezpieczam sie na wypadek linczu, bo to nie bylo ze tak powiem sensem
> mojej wypowiedzi] ;) W kazdym razie takie funkcje sa (powinny byc)
> realizowane na poziomie sprzetu, o ile sie nie myle. Ewentualnie sa
> dublowane potem na poziomie protokolu programowego, ktory chodzi po tym
> (ppp). I wlaczenie kompresji ppp (bo od tego chyba sie dyskusja zaczela?;)
> nie spowoduje zadnego problemu. Nie oznacza dokladania nowych chipow, nie
> powinno wydluzyc czasu potrzebnego na resynchronizacje polaczenia po tym,
> jak poleci kilka bledow, nie ma tez nic wspolnego z tym, co wyciagali
> tutaj ludzie, czyli predkoscia modem / terminal <-> port szeregowy (bo
> kompresja na poziomie ppp pozwala wcisnac wiecej danych w strumien
> sprzetowy o przepustowosci 115200). Trywialne algorytmy kompresji (typu
> deflate) nie powinny tez byc szczegolnym wyzwaniem dla oprogramowania po
> stronie serwera obslugujacego ppp w centrali.
W 100% prawda! Pozostaje "tylko" czekac, az przeczyta to ktos
odpowiedzialny za SDI w TP SA i wlaczy te kompresje w urzadzeniach
dostepowych.
> A tak wracajac do podstaw - czy ktos wlasciwie wie (w 100%) czy ppp
> chodzace po HISach w koncu wspiera kompresje (a tylko czlowiek pytajacy
> na poczatku nie wiedzial, jak ja wlaczyc), czy nie?:>
Na 100% nie - w logach mozna obejrzec, ze nie udaje sie wynegocjowac
protokolu kompresji.
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 16:35:49 MET DST