Stachu 'Dozzie' K.
6/14/2007 7:36:00 PM
On 14.06.2007, Marcin <news_reader@poczta.onet.pl> wrote:
> Zastanawiam sie ostatnio nad najlepsza implementacja malego systemu
> "gadajacego" poprzez komunikaty. Od razu pisze, ze tez chce na tym
> skorzystac edukacyjnie wiec uzywanie gotowych bibliotek - jesli sa - raczej
> mnie nie intersuje. Oczywiscie chetnie przegladnalbym jakis dobrze napisany
> przyklad (najlepiej open source), wiec jesli ktos zna cos godnego
> polecenia - bylbym zobowiazany ;-)
> Mam tez pytanie odnosnie samej organizacji komunikatu i transportu. Od
> razu napisze, ze nie chodzi mi raczej o komunkat typu "xml wysylany poprzez
> siec".
> 1. Jaka jest Waszym zdaniem najlepsza struktura komunikatu. Najbardziej
> bezpieczna jest chyba ta ze stala dlugoscia ale z drugiej strony najmniej
> rozwojowa.
Tak.
> 2. Jaka jest najoptymalniejsza zawartosc naglowka. Kolejno: Dlugosc,
^^^^^^^^^^^^^^^^^-- najbardziej najlepsza?
> Wersja_Protokolu, Opcode, Subopcode, CRC_Naglowka ? Dla krotkich komunikatow
> to troche chyba zbyt duzo ?
Nie.
> 3. Czy jest sens stosowac obok naglowka takze czesc konczaca (trailer) ?
48.
> 4. Jak jest w kwestii wysylania. Rozumiem, ze po stronie nadawczej, pakuje
> wszystko w strukture (najlepiej spakowana) i wolam funkcje typu send. Ale
> jak jest z odbieraniem ? Socket odbierajacy powinien najpierw pobrac znana
> ilosc bajtow jako naglowek a potem ewentualnie doczytac zawartosc ? Co jesli
> naglowki sa rozne w zaleznosci od wersji ? Czyli najpier wersja protokolu ?
Czerwony.
Te pytania, podobnie jak powy?sze odpowiedzi, nie maj? wiekszego sensu,
bo nie rozmawiamy o konkretnym protokole i konkretnych problemach,
którym protokó3 ma stawia czo3a.
> 5. Niezbyt wiem jak traktowac problem atakow typu wysylanie wadliwych
> komunikatow do odbiorcy ? Zakladajac, ze odbierajacy serwer to jakas usluga
> o dobrze_znanym porcie, to atakujacy moze wysylac komunikaty np. z blednie
> ustawiona wartoscia pola dlugosc co powoduje to, ze potem 'doczytamy' zbyt
> duzo lub zbyt malo ?
W protokole strumieniowym bez uwierzytelniania stron po3?czenia sie nie
obejdzie. Jedynie timeout mo?e pomóc.
W protokole datagramowym operacja read() zwróci po prostu mniej danych.
> 6. Czy wg. Was metoda pol CRC dla calosc, dla naglowka lub dla danych jest
> dobra metoda na zabezpieczenie sie przed 5 ?
CRC to oko3o 32 bity. To nie jest du?o. Je?li zadajesz takie pytania to
nawet nie próbuj transmisji zabezpieczaa na w3asn? reke i skorzystaj
z gotowych rozwi?zan (SSL, TLS).
> 7. Jak wyglada w praktyce kwestia UDP vs TCP ? Co lepiej stosowac w tego
> typu komunikacji ? Czy strumieniowosc TCP nie pasuje do messagingu jak wol
> do karety ?
A w SSH co sie przekazuje, jak nie komunikaty w3a?nie? I po czym biega
sobie SSH?
> Z drugiej strony wysylajac przez UDP musze nianczyc w aplikacji
> retransmisje, fragmentacje (jak dobrac wielkosc fragmentow - testowanie
> linka przy starcie to chyba glupi pomysl, bo za chwile routery moga wybrac
> juz inna trase), oraz pakiety przychodzace w zlej kolejnosci ?
Jakby? zgad3.
> 8. Czy znacie moze jakas dobra ksiazke na temat protokolow. Nie chodzi mi o
> konkretny protokol (rfc moim przyjacielem jest) ale raczej pozycja ktora
> mowi jak atakowac konkretne klasy problemow (np. jesli to jest system w
> elektrowni atomowej to wyrozna go niezawodnosc, hard real time oraz
> gwarantowanie dostarczenie komunikatu. Aby uzysak to mamy takie techniki ...
> czyli inaczej mowiac design patterns dla tego tematu). Moze jakies ciekawe
> case study ?
RFC-ki na ogó3 maj? do?a dobrze opisane problemy pojawiaj?ce sie przy
danym protokole.
> 9. Czy sa jakies szczegolne problemy przy stosowaniu tego rodzaju
> komunikacji dla urzadzen bezprzewodowych (Teraz w prawie kazdym
> telefoniejest jakis GPRS albo inny EDGE i dodatkowo mozna czasami napisac
> cos swojego) ?
>
> Z gory dziekuje za uwagi
> Marcin
>
>
--
Secunia non olet.
Stanislaw Klekot