[inne]Format kompresji + error control, naprawa uszkodzonych danych Opcje

[wNogachSpisz]

Witam
Mój problem jest natępujący - borykam się z losowymi błędami w danych przesyłanych za pomocą poczty elektronicznej.
Zdarza się że dane z załącznika są binarnie przesunięte o jeden bajt w kilku miejscach.
Taki błąd ma miejsce niezbyt często, powiedzmy raz na 200 wiadomości, 2-3 bajty są przesunięte.
Czytam, czytam i okazuje się że usenet cierpi na podobne przypadłości i niewiele można na to poradzić :/
Dziwne, ale prawdziwe.
Szukam dobrego sposobu na pozbycie się tego problemu.
Myślę że archiwizacja przy pomocy formatu zdolnego wykryć i naprawić błąd może być rozwiązaniem (error control).
Czy ktoś zna taki format natywnie wspierany przez PHP ?
Nie chodzi mi rzecz jasna o sume kotnrolną całej wiadomości, tylko o naprawę błędu.

Z góry dzięki za pomoc!

[erix]

No z takimi szczegółami, to na pewno coś poradzimy. (IMG:style_emoticons/default/smile.gif)

[wNogachSpisz]

No z takimi szczegółami, to na pewno coś poradzimy. (IMG:style_emoticons/default/smile.gif)

Czy to jest odpowiedź? Jeśli tak to nie rozumiem.

Modyfikuje swoje pytanie, nie musi być format kompresji, wystarczy mi jakiekolwiek kodowanie korekcyjne (FEC).

Ten post edytował wNogachSpisz 26.11.2011, 19:16:10

[abort]

Czekaj, bo nie rozumiem.
"losowe błędy w poczcie" - na razie wiem(y) tylko, że jeden bajt jest przesunięty.
Potem słyszymy, że na ok.200 wiadomości 2-3 bajty są przesunięte.
potem czytamy, że usenet tez cierpi na podobne przypadłości, o czym "czytasz i czytasz".

Pytania wspomagające:
1. możesz wziąć pod lupę tę losowość i zawęzić ją do poszczególnych MUA (Mail User Agent)? Które MUA wykluczamy, a którym się przyglądamy?
2. Mówimy o nagłówkach, treści czy załącznikach? A jeśli o załącznikach, to czy zdarza się to jakoś szczególnie często w odniesieniu do jednego typu załącznika (bo zakładam, że o załącznikach piszesz)?
3. Jesteś w stanie takiego maila gdzieś opublikować? Ja rozumiem, że załączniki mogą zawierać jakieś poufne firmowe dane, ale... może znajdzie się coś, co można "pokazać światu"?

Mając do dyspozycji kilkadziesiąt (a lepiej: kilkaset) błędnych wiadomości, można się pokusić o jakiś rozkład tego błędu w funkcji MUZ czy też typu załącznika. I piszę to mimo tego, że wiem, że 200*kilkaset to już jest milion - ale jeśli jest tyle literatury na sieci, to zakładam, że ktoś dysponuje choćby fragmentarycznymi danymi...

Po forumowiczu z Twoim stażem spodziewałbym się przynajmniej linków do źródeł na sieci - bo po tak ogólnikowym sformułowaniu pytania nie poradzę nic. A temat mnie interesuje, bo od 1993r nie spotkałem się z opisanym przez Ciebie błędem w żadnym popularnym MUA (czy też MTA). Uwierz mi, nie zam MUA/MTA który by zniekształcał pocztę - to się kwalifikuje na zgłoszenie bugreportu do autorów...

[wNogachSpisz]

Niestety ten błąd nie jest powtarzalny.
Jedna na 200 wiadomości ma błąd polegający na przesunięciu 3-4 bajtów o 1 w górę, np. chr(200) staje się chr(201).
Mija kilka godzin i albo błąd ustępuje (pobrana wiadomośćjest identyczna z oryginałem) albo przesunięcie ujawnia się w innych bajtach.

Takie rzeczy mogą się zdarzać gdy przesyła się dane "binarnopodobne".
Nie zdebugujesz tego, nie da się.

Zostawmy to i skupmy się na algorytmach korygujących błedy..


Jeśli chodzi o MUA to jest nim PEAR::Net_POP3

Ten post edytował wNogachSpisz 26.11.2011, 20:03:45

[abort]

Aby korygować błędy, musisz mieć wzorzec. Nie mając dostępu do wzorca, nic nie zdziałasz. Tak samo działa cały protokół TCP/IP, gdzie każda ramka ma swoje CRC. Nadawca opakowuje paczkę danych, oblicza jego CRC, i buduje z tego pakiet (w pakiecie jest jeszcze kilka innych pól, ale my skupiamy się ma polach z danymi). Odbiorca ma pakiet - wypakowuje z niego dane, oblicza CRC (algorytm jest oczywiście publicznie znany), porównuje z tym, co jest w pakiecie zapisane przez nadawcę, i jeśli wszystko się zgadza, wysyła do nadawcy pakiet z ustawioną flagą "ACK", oznaczającą potwierdzenie otrzymania i poprawności danych. Jeśli coś się nie zgadza, wysyła (AFAIK) ACK+PSH, które jest informacją dla nadawcy, że coś zmieniło pakiet po drodze, a jednocześnie informacją dla nadawcy "prześlij mi ponownie pakiet - coś mi się nie zgadza".

Ty jesteś w sytuacji, w której masz tylko dane. Nie widzę w tej sytuacji możliwości manewru. Na przykładzie działania TCP/IP widać wyraźnie, że do wprowadzenia jakiegokolwiek sposobu na sprawdzenie integralności danych jest potrzebne:
1. algorytm - to nie problem, md5 i sha1 aż się rwą do tego
2. implementacja go u nadawcy - tu jest problem, bo na to nie masz wpływu
3. implementacja u odbiorcy

Częściowo mógłbyś ten temat ugryźć z pomocą funkcji typu md5 czy sha1 - ale nadawca musiałby podawać funkcje skrótu dla przesyłanych plików. Masz jakikolwiek sposób, aby nadawcę do tego zmusić?

Ten post edytował abort 26.11.2011, 20:19:58

[wNogachSpisz]

Kodowanie korekcyjne lub kodowanie korygujące (ang. ECC - error correction coding, FEC - forward error correction) – technika dodawania nadmiarowości do transmitowanych cyfrowo informacji. Umożliwia całkowitą lub częściową detekcję i korekcję błędów powstałych w wyniku zakłóceń. Dzięki temu nie ma potrzeby wykorzystywania kanału zwrotnego, do poinformowania nadawcy o błędzie i konieczności ponownego przesłania informacji. Kodowanie korekcyjne jest więc wykorzystywane wtedy, gdy retransmisja jest kosztowna, kłopotliwa lub niemożliwa, np. ze względu na ograniczenia czasowe.

Ty mówisz o tworzeniu sum kontrlnych dużych bloków danych i ponowne przesłanie porcji danych w razie wykrycia błędu.
Natomiast ja mówie o dodawaniu nadmiarowości co umożliwia wykrycie i naprawę błędu w dowolnej chwili.
Blisko, jednak nie to samo.

Parchive robi dokładnie to co chce..
http://parchive.sourceforge.net/
Tyle że to nie jest w php :/

Ten post edytował wNogachSpisz 26.11.2011, 20:30:24

[abort]

IMHO nawet FEC/ECC nie zrobisz. Powód podałem w poprzednim poście, wytłuszczoną czcionką.
Chyba że base64 lub inne algorytmy używane do przesyłania danych binarnych protokołem (E)SMTP mają to zaimplementowane.
Choć szczerze mówiąc, to wątpię, by tak było - argument: gdyby tak było, nie byłoby tylu informacji na sieci, że "nie działa". Byłoby mniej, a w dodatku miałbyś od razu na forach odsyłacz do dokumentacji, jak sprawdzić integralność (IMG:style_emoticons/default/smile.gif)

[wNogachSpisz]

Tyle że ja nie chce tego nigdzie implementować, nie ma takiej potrzeby!
Używam własnego clienta zarówno do wysyłania i odbierania, wystarczy że zrobi on enkapsulacje przed wysłaniem i dekapulacje po odebraniu.

Staram się lecz nie potafie rozumieć o co Ci chodzi :/

Ten post edytował wNogachSpisz 26.11.2011, 23:48:10

[abort]

Nie wiem, może jestem przymulony, bo odpowiadałeś na moje pytanie o MUA - ale ja zrozumiałem to jako info o MUA odbiorcy. Nic nie pisałeś o MUA nadawcy, a może ja też nie dopytałem wyraźnie...

OK, jeśli narzucasz MUA zarówno nadawcy, jak i odbiorcy, to sprawa staje się prostsza. Przed wysłaniem przekonwertuj plik do postaci "z danymi korekcyjnymi", żeby w transmisji poszły też dane korekcyjne, a przy odbiorze je wykorzystaj. Nie widzę w tym problemu. Oczywiście poza czasem (wybór metody, implementacja).

Natomiast co do natywnego formatu załączników w poczcie: na początku był to duet uuencode/uudecode, które później zostały wyparte przez base64. Od tego czasu nic się nie pojawiło. Wnioskuję z tego, że jednak problem leży w PEAR::Net_POP3, nie wyobrażam sobie błędu gdzie indziej.

[wNogachSpisz]

Wnioskuję z tego, że jednak problem leży w PEAR::Net_POP3, nie wyobrażam sobie błędu gdzie indziej.

Wątpie.
Myśle że serwer nie jest dobrze przystosowany do pracy z danymi binarnymi i raz na jakiś czas coś mu sie chrzani.
Bardzo to dziwne wiem, nie widać oczywistej przyczyny.

base64 to zgroza, serwer obsługuje 8 bitowe załączniki, to dlaczego tego nie wykorzystać..
Chyba że 30% oszczędności zarówno na przestrzeni dyskowej jak i transferze to drobnostka.

Może wróćmy do tematu.
Jakiego algorytmu użyć?

[abort]

- Myśle że serwer nie jest dobrze przystosowany do pracy z danymi binarnymi i raz na jakiś czas coś mu sie chrzani.
Sugerujesz, że wszystkie przypadłości opisane na sieci mają związek z jednym serwerem (w sensie oprogramowania)? Myślę, że wątpię. Jeśli już masz jakiś wpływ na to, co stoi na serwerze, to najprędzej winę może ponosić demon POP3 - proponuję potestować na innym.

- "base64 to zgroza, serwer obsługuje 8 bitowe załączniki, to dlaczego tego nie wykorzystać.." Chyba że 30% oszczędności zarówno na przestrzeni dyskowej jak i transferze to drobnostka.
Masz alternatywę: albo stracić 30% na base64, albo stracić ileś % (nie wiem ile - ale szacuje na > 10%) dysku i ileś procent mocy CPU (razy dwa). Jak dla mnie - wybór między dżumą i cholerą.

- Jakiego algorytmu użyć?
Oj, tu nie poradzę - ten temat to dla mnie terra incognita - ale jest to też jedna z przyczyn, dla których próbuję Ci pokazać inne rozwiązania. Bo implementowanie N algorytmów i subiektywne ich ocenianie to naprawdę czasochłonne zajęcie. Prościej poszukać błędu gdzie indziej, a że on występuje, to sam dobrze wiesz.

[wNogachSpisz]

Jeśli już masz jakiś wpływ na to, co stoi na serwerze, to najprędzej winę może ponosić demon POP3 - proponuję potestować na innym.

Gadałbym dokładnie tak samo na Twoim miejscu.
Różnica między nami polega na tym, że testuje to od 3 dni, wykluczyłem wszystko, pozostaje diagnoza że serwer ma kaprys. Błąd widać w TCPDUMP więc klient pocztowy nie ma tu nic do rzeczy.

Masz alternatywę: albo stracić 30% na base64, albo stracić ileś % (nie wiem ile - ale szacuje na > 10%) dysku i ileś procent mocy CPU (razy dwa). Jak dla mnie - wybór między dżumą i cholerą.

Owszem, kodowanie w php trwa potwornie długo, mimo to myśle że warto.
Źle szacujesz, nie 10% a 1-2%.

Oj, tu nie poradzę - ten temat to dla mnie terra incognita - ale jest to też jedna z przyczyn, dla których próbuję Ci pokazać inne rozwiązania. Bo implementowanie N algorytmów i subiektywne ich ocenianie to naprawdę czasochłonne zajęcie. Prościej poszukać błędu gdzie indziej, a że on występuje, to sam dobrze wiesz.

Dlatego poświęciłem na to 3 dni i doszedłem do wniosku, że najlepsze rozwiązanie to kodowanie korygujące.


Pozwole sobie założyć nowy temat..

Ten post edytował wNogachSpisz 26.11.2011, 22:06:40