W dniu 2014-08-07 12:32, jacek pozniak pisze:

> Ot choćby te UDP; ja na przykład nie wiedziałbym jak przez UDP połączyć się
> z tym serwerem wykorzystując ogólnie dostępne narzędzia typu przegladarka
> www (lub wget czy też curl, choć te to chyba potrafią). Do tego chyba
> potrzebne jest TCP więc funkcjonalność polegająca na UDP jest co najmiej
> mało użyteczna.

Żadne z powyższych narzędzi do tego nie służą. Zresztą przesyłanie
danych pakietami UDP nie jest rozwiązaniem dla końcowego użytkownika, za
to w ten sposób można fajnie zrealizować komunikację M2M. Stawianie
serwera WWW na mikrokontrolerze celem generowania jakiegoś prostego GUI
mija się z cele, przynajmniej takie jest moje zdanie. Lepiej wykorzystać
do tego jakiś istniejący serwer, a jeśli go nie ma - postawić (chociażby
na Raspberry Pi) i to jego skomunikować z czujką czy sterownikiem na MCU.


> Kolejna rzecz to DHCP; wierz mi lub nie, ale jeśli będziesz chciał z tym
> wyjść poza swój stół warsztatowy to nie ma opcji.

A po co mi DHCP, jeśli chcę, żeby urządzenie było łatwo identyfikowalne
w okolicznej sieci? Ok - można co chwilę prosić wszystko dookoła, żeby
łaskawie się przedstawiło, bo właśnie pozmieniała się konfiguracja
numerów IP. W mojej lokalnej sieci z DHCP korzystają praktycznie tylko
mobilne urządzenia WiFi. Wszystko inne pracuje na swoich własnych, na
stałe przypisanych numerach.


> A to dopiero warstwa dość niska; na tym jeszcze trzeba zrobić jakiś
> interfejs do konfiguracji ustrojstwa, najlepiej aby był czytelny dla
> człowieka i nie polegał jedynie na przesyłaniu jednobajtowych instrukcji bo
> po miesiącu się zapomina co jaka znaczy.

Telnet i konsola w zupełności wystarczą.


> chyba coś koło 20 bajtów (piszę z głowy RemoteIP remote_port, local_port,
> seq1, seq2 i coś tam jeszcze.)

Hmm... A tak z ciekawości, to jak buforowana jest sama wiadomość, na
wypadek, gdyby pakiety ją zawierające dotarły w niewłaściwej kolejności?
No chyba, że stos odrzuca "późniejsze" pakiety, zanim nie przetrawi
tego, na który czeka?