On 30/04/2020 09:33, Zbych wrote:
>> Innymi słowy aby mieć porządny stos TCP/IP musisz mieć solidny
>> procesor z MMU, kilkadziesiąt MB biblitek do obsługi preemptive
>> mutitaskingu, filesystemu, logowania, praw dostępu, obsługi eventów,
>> oopsy do kompletu i koniecznie jakiegoś backdoora. I to wszystko aby
>> przesłać kilka bajtów z lewa na prawo.
> Jeśli ten procesor i RAM kosztuje grosze to czemu nie?

Ponieważ każda z tych zbędnych warstw wprowadza dodatkowe miejsca gdzie:
a) czają sie błędy
b) nie da się czegoś zweryfikować
c) zwiększają czasy reakcji
d) zwiększają złożoność setki razy powyżej spodziewanej

W sytuacji gdy chcesz to wsadzić do urządzenia podlegającego jakiejś
certyfikacji każda z tych rzeczy jest kłopotliwa bądź niemożliwa do
przepchnięcia.

> Wolę mieć
> przetestowany soft

Czyli Linux odpada. Chyba że zakładasz że "przetestowany" oznacza milion
instalcji Ubuntu do oglądania porno na pecetach. Obawiam się że
"przetestowany" może nie dotyczyć konkretnego niszowego rdzenia uC.

> , który pracuje na milionach serwerów 24/7

A one zaś wszystkie pracują na Twoich mikrokontolerach ...

Zaznaczam że fakt odpalenia się Linuxa na jakimś rdzeniu CPU nie oznacza
że będzie "przetestowany". W zasadzie błedy krytyczne spotykane są do
dzisiaj, a im mniej popularna platforma tym jest ich więcej. A że
platformy dla linuxa są skomplikowane z definicji, no to wiadomo że
łatwo nie będzie ...

Z drugiej strony jeśli weźmiesz jakiś procesor o prostej konstrukcji,
szanse na błędy w obsłudze hardware maleją. Możesz pisać na odpierdol i
zakładać że jak coś padnie to się najwyżej zrestartuje, ale są miejsca
gdzie jak coś padnie to spadnie. Na da się pisać bezbłednie, ale znamy
metody eliminacji błędów na etapie produkcji kodu, zdecydowana większosc
z nich nie jest w stanie ogarność złożonych systemów jak linux.

> i który nie
> klęknie po dostaniu kilku niezakończonych handshaków

Za to klęknie bo kto zapomniał wyłaczyc loga aż zajechało cały
filesystem. Albo klęknie bo masz buga w preemptive multitaskingu który
wysoczył dopiero po 40 miesiącach nieprzerwanej pracy bo się hardwareowy
licznik przekręcił. Albo okazało się że to przerwanie nigdy nikomu nie
przyszło w tym samym momencie co operacja na Flashu, a Ty jesteś
pionierem. Możesz pozerkać na grupy dysusyjne OpenWRT gdzie ludzie
miewali dokładnie takie zabawne problemy z tym "przetestowanym linuxem"
jak przerwania rebootujące system, problemy z koherencją cache itd itp.
I oni w zasadzie implementują linuxa na takich małych pizdrykach, SoC. I
jakimś trafem fakt że milion instancji Ubuntu do oglądania porno nijak
nie poprawia stabilności jajka w SoC Atherosa.

>, albo stada
> pofragmentowanych pakietów.

Co akurta jest oczywistym problemem do rozwiązania jak się pisze stos
TCP. Oczywiście można napisać kiepski stos TCP. Ale szczęśliwie lata
60te w programowaniu minęły, teraz mamy techniki zapewniajace jakość i
pilnujące specyfikacji.

> A także taki, który będzie można rozbudować
> o szyfrowanie transmisji, VPN jeśli będzie to konieczne.

Ale tu nie było konieczne. Ot, ktoś wsadził napisany na odpierdol w
perlu serwer tcp->rs485 i skasował za "nowoczesny design". Dzień jak co
dzień.