[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!

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