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!

No z takimi szczegółami, to na pewno coś poradzimy.

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

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

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...

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

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ć?

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 :/

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ść

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 :/

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.

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ć?

- 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.

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.


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


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..