Witam
Nie znalazłem w sieci aby ktoś w języku polskim omawiał jakie są różnice między zeromq a normalnym API od socketów. Tzn. chodzi o różnice dlaczego zeromq jest lepsze. Po angielsku to znajdujesz jedynie takie hasła z których nic nie wynika, które brzmią jak to kandydaci na wybory startują. A więc w przypadku zeromq to będzie że jest lekkie, ma dużą społeczność, end to endpoint encryption cokolwiek to znaczy, ma mesydż framing (cokolwiek to znaczy), jest przenośne, jest super szybkie, ma implementacje w wielu językach programowania, można za pomocą tego pomiędzy wątkami gadać (to użyając API sockdddr_in/un nie można?), jest reliable, ma bounded buffer (cokolwiek to znaczy) itp. itd. tak że jak to przeczytasz to i tak nie wiesz na czym tkwi przewaga zeromq nad tym co do tej pory znałeś.

Więc jak ktoś ma coś do dodania to proszę o napisanie w tym wątku dlaczego zeromq jest lepsze. Ja ze swojej strony rozpocznę:

  1. API zeromq jest bardziej zwięzłe co sprawia że kod jest bardziej czytelny i przejrzysty, szybciej się pisze kod. Po stronie serwera po zbindowaniu nie trzeba wywoływać metody listen, accept, tylko od razu przechodzisz do pętli while(1) i metody nasłuchującej i blokującej recv.

  2. W przypadku normalnych socketów (SOCK_STREAM) najpierw trzeba wystartować serwer, musi on zbindowac gniazdo na adres ip/port (czy ścieżkę w domenie AF_UNIX) i dopiero wtedy możesz wywołać connect po stronie klienta bo inaczej to connect zwróci ci error że socket nie istnieje. Natomiast w zeromq obojętnie czy uruchamiasz najpierw proces klienta czy serwera.

  3. Załóżmy że po stronie klienta zrobiłeś connect i w pętli "for" 100 razy odpaliłeś write/send. Po stronie serwera natomiast połączenie zostało zaakceptowane po czym wywołałeś read/recv. Załóżmy że procesor po stronie serwera jest znacznie szybszy od tego po stronie klienta. W tym przypadku może być tak, że nie wszystko serwer dostanie, wyjdzie on z reada jeszcze jak write po stronie klienta będzie wykonywany.
    W przypaku zeromq przy wysyłaniu 100 mesydzów ustawisz sobie flagę że jest to multipart mesydż, przy setnej iteracji ustawiasz w sendzie że jest to ostatni mesydz i jest gwarancja że serwer wszystko odbierze co wysłałeś. Z tego powodu zeromq jest bardziej reliable.

  4. Zeromq jest bardziej niezawodne również dlatego że zarówno po stronie klienta/serwera komunikacja działa w ten sposób że najpierw wysyłasz/oczekujesz na odbiór a potem oczekujesz na ACKa/wysyłasz Acka. Jeśli po stronie klienta zrobisz 2 razy send i nie oznaczysz że jest to multipart mesydz to zawiesisz klienta, bo on ma wewnętrzną stanologię, Po wysłaniu mesydza musisz oczekiwać na ACKa od serwera. Po stronie serwera po odebraniu mesydza musisz wysłać ACKa do klienta.

  5. Jest dużo mesydż patternów w zeromq REQ-REP, PUB-SUBSCRIBER, do komunikacji n-endpoints to n-endpoints. Być może w normalnych socketach też coś jest, ale każdy raczej używa tego do komunikacji 1endpoint to 1 endpoint

To tyle co zauważyłem, tych angielskich przymiotów dlaczego zeromq takie super to nie rozumiem. Pewnie musiałbym spędzić wiele godzin by się jeszcze bardziej wgłębić w API normalnych socketów jak i zeromq oraz w samą wiedzę odnośnie protokołu TCP wtedy by może coś mi to powiedziało więcej.