Używanie ZeroMQ razem z Boost:: ASIO

W końcu doszedłem do wniosku, że są dwa możliwe rozwiązania:

• Sam Miller używa pętli zdarzeń ASIO
• pętla zdarzeń ZeroMQ poprzez pobranie deskryptorów plików ASIO za pomocą metod .native() acceptor i socket i wstawienie ich do tablicy zmq_pollitem_t

Zaakceptowałem odpowiedź sama Millera, ponieważ jest to dla mnie najlepsze rozwiązanie w przypadku SCGI, gdzie tworzone są i kończone stale nowe połączenia. Obsługa każdej zmiany zmq_pollitem_t tablica jest dużym kłopotem, którego można uniknąć używając pętli zdarzeń ASIO.

Uzyskanie gniazda do ZeroMQ jest najmniejszą częścią bitwy. ZeroMQ opiera się na protokole , który jest warstwowy nad TCP, więc będziesz musiał ponownie zaimplementować ZeroMQ w niestandardowym Boost.Asio io_service jeśli jedziesz tą trasą. Ten sam problem napotkałem podczas tworzenia usługi asynchronicznej ENet przy użyciu Boost.Asio najpierw po prostu próbuje złapać ruch z klienta ENet za pomocą Boost.Serwis ASIO UDP. ENet jest protokołem TCP podobnym do UDP, więc wszystko co osiągnąłem w tym punktem było łapanie pakietów w praktycznie bezużytecznym stanie.

Boost.Asio jest oparte na szablonach, a wbudowane io_service używają szablonów, aby zasadniczo owinąć bibliotekę gniazd systemowych w celu utworzenia usługi TCP i UDP. Moim ostatecznym rozwiązaniem było stworzenie niestandardowej usługi io_service, która owijała bibliotekę ENet, a nie bibliotekę gniazd systemowych, pozwalając jej na korzystanie z funkcji transportowych ENet, a nie na ich ponowne implementowanie przy użyciu wbudowanego transportu UDP.

To samo można zrobić dla ZeroMQ, ale ZeroMQ jest już bardzo wydajną biblioteką sieciową, która sama w sobie zapewnia asynchroniczne wejścia/Wyjścia.myślę, że możesz stworzyć realne rozwiązanie, odbierając wiadomości za pomocą istniejącego API ZeroMQ i przekazując je do puli wątków io_service. W ten sposób wiadomości / zadania będą nadal obsługiwane asynchronicznie za pomocą Boost.Schemat reaktora Asio bez konieczności ponownego pisania czegokolwiek. ZeroMQ zapewni asynchroniczne I / O, Boost.Asio dostarczy zadanie asynchroniczne opiekunowie/pracownicy.

Istniejący io_service może być nadal podłączony do istniejącego gniazda TCP, umożliwiając threadpool obsługę zarówno TCP (w Twoim przypadku HTTP), jak i ZeroMQ. Jest to całkowicie możliwe w takiej konfiguracji, aby procedury obsługi zadań ZeroMQ miały dostęp do obiektów sesji usług TCP, co pozwala na wysyłanie wyników wiadomości/zadania ZeroMQ z powrotem do klienta TCP.

Poniżej znajduje się tylko ilustracja tego pojęcia.

// Create a pool of threads to run all of the io_services.
std::vector<boost::shared_ptr<boost::thread> > threads;
for(std::size_t i = 0; i < thread_pool_size_; ++i) {
    boost::shared_ptr<boost::thread> thread(new boost::thread(boost::bind(&boost::asio::io_service::run, &io_service_)));
    threads.push_back(thread);
}

while (1) {
    char buffer [10];
    zmq_recv (responder_, buffer, 10, 0);
    io_service_.post(boost::bind(&server::handle_zeromq_message, buffer, this));
}

Rozwiązaniem jest również sprawdzenie io_service zamiast run ().

Sprawdź To rozwiązaniedla jakiegoś poll() info.

Użycie poll zamiast run pozwoli na sprawdzenie połączeń zmq bez problemów z blokowaniem.