2012-08-02 14 views
9

Jestem obecnie używający zmq z python. Serwer korzysta z gniazda REP.ZMQ REP, wiedząc, kto wysyła zapytanie

Czy mam sposób, aby odebrać wiadomość, aby dowiedzieć się, kto ją wysyła? Jeśli odbierasz 2 wiadomości, po prostu muszę wiedzieć, czy pochodzą od tego samego użytkownika, czy nie, więc wystarczy na przykład uid.

Odpowiedz

2

Czytanie http://zguide.zeromq.org/page%3aall#Transient-vs-Durable-Sockets, możesz uzyskać tylko tożsamość gniazda, z którym pracujesz ... nie jest to gniazdo z żadnymi innymi urządzeniami, z którymi jesteś połączony.

Mówiąc to, po prostu skompiluj informacje o nadawcy do wiadomości. Powinno to być trywialne (z UUID lub określoną nazwą na klienta).

+0

Wielkie dzięki za to. Tak, moja wiadomość będzie zawierała informacje o nadawcy (prawdopodobnie jako uid jeszcze nie wiem). Wolałbym wziąć informacje z gniazda, ponieważ pozwalając użytkownikowi podać informacje, pozwala mu to zrobić session_hijack (nawet jeśli jest to mało prawdopodobne, abym się zgodził) – user1572602

+0

dobrze, że nie "pozwól" im ustawić ID. otrzymają od ciebie swój identyfikator po procesie uwierzytelnienia. Ten nowy identyfikator zmienia się za każdym razem, gdy jest autoryzowany. Zasadniczo eliminuje to prawie wszelkie zagrożenia związane z porwaniem sesji. – g19fanatic

+0

Również, jeśli ta odpowiedź była pomocna, proszę oznaczyć ją jako tak :) – g19fanatic

14

Wygląda na to, że chcesz zaimplementować obsługę żądań asynchronicznych po stronie serwera: pozwalasz serwerowi akceptować żądania, przetwarzać je asynchronicznie i wysyłać odpowiedzi do klientów, gdy dane odpowiedzi są dostępne dla każdego żądania. Teraz oczywiście: skąd wiesz, po zakończeniu przetwarzania żądania, do którego klienta należy go wysłać?

Dzięki prostym gniazdom REP ØMQ zapewnia, że ​​nie napotkasz na ten problem, wymuszając sekwencyjność recv() -> send(), recv() -> send(). Innymi słowy, po zrobieniu recv() na gnieździe REP, użytkownik ma, aby ponownie wykonać operację z poziomu send(). Odpowiedź zostanie odesłana do klienta, z którego otrzymałeś wiadomość, i nie ma wątpliwości co do adresu klienta, ponieważ jest to tylko jeden klient naraz.

Ale to naprawdę nie pomaga, gdy chcesz zrównoleglić obsługę żądań, prawda? Istnieje wiele przypadków, gdy zachowanie REP jest zbyt restrykcyjne i właśnie do tego służą komunikaty Multipart i gniazda ROUTER (lub XREP). XREP łamie blokadę REP na recv() -> send(), ale powoduje to problem, jak widzieliśmy wcześniej - w jaki sposób wysłać odpowiedź do klienta, który wysłał żądanie, jeśli wielu jest połączonych? Aby to umożliwić, XREP w ZeroMQ dodaje część wiadomości na początku wiadomości, podobnie jak kopertę, która zawiera tożsamość połączenia, z którego pochodzi.

Istnieje cały rozdział w Przewodniku ZMQ na temat advanced Request-Reply patterns. Można również znaleźć przykład obsługi żądań asynchronicznych here i dobre krótkie wyjaśnienie obsługi połączenia ZeroMQ here.