Pewna Transmisja RS232

pdusp:

wyślij dodatkowo numer komunikatu w paczce bajtów i w odpowiedzi. Powinien wystarczyć bajt. Po obu stronach sprawdzasz, czy numerki się zgadzają.

Waldek

Czyli warto przeczytac RFC protokolu TCP. Moze to nasunac sporo ciekawych rozwiazan na kontrole przesylu danych.

T.M.F.:

nie wiem, czy warto, ale można. Można zaimplementować stos TCP i zrobić TCP-RS, ale to zależy od prędkości transmisji i czy nadajnik wysyła komunikaty "na zapas".

Waldek

albo w ogole uzyc TCP a po RS puscic jakis SLIP albo PPP.

Ale wracajac do poczatku - poza numerem komunikatu (nawet 1 bit) trzeba zastosowac timeouty i retransmisje. TCP obejmuje tez rozne dziwne przypadki, ktore w RS raczej sie nie zdarzaja - np. zamiane kolejnosci paczek. Wynika to z tego, ze TCP funkcjonuje tylko pomiedzy skrajnymi komputerami, a po drodze jest/moze byc wiele urzadzen retransmitujacych. Prostsze sa techniki stosowane np. w protokole ZMODEM.

Krzysiek Rudnik

Poczytać to może warto, ale implementować na pewno nie;)

Do pewnej transmisji po zlaczu szeregowym ludzie wymyslili np. protokoly X/Y/Z-modem. Oczywiście wszystko zależy od wymagań niezawodnościowych (nie istnieje coś takie jak 100% pewności:), dostępnej mocy obliczeniowej/pamięci czy kosztów.

Można softwarowo, można zastosować jakieś HW (FPGA) i zrealizować detekcję błedów, kodowanie nadmiarowe czy retransmisje. Mogą to być TCP czy jakieś protokoly sieci przemyslowych itp.

Ale bez przesady - stawianie wymagania, że nic nie może być zgubione to abstrakt tej samej klasy co linia prosta. Jest, tylko nikt jej nie widział (zwłaszcza budowlańcy;)

Kermit ;-), Hydra, Puma, Janus. Samych X-modemów masz ze 3. Y-modemów również. Najmniej problemów ze zgodnością daje chyba Kermit i ZModem. Najpewniejszy z nich, to oczywiście ZModem.