boost-asio как «шаблон» для демона

Я пытаюсь превратить некоторый демонстрационный код, который запускается как консольное приложение в Linux, в демона.

SDK находится на c ++, поэтому я искал код на c ++, который выполняет все, что нужно демону: запуск, разветвление, отсоединение, перенаправление std coms в системный журнал, обработку сигналов и т. Д.

Итак, я нашел этот пример:

// daemon.cpp
// ~~~~~~~~~~
//
// Copyright (c) 2003-2011 Christopher M. Kohlhoff (chris at kohlhoff dot com)
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
//

#include <boost/asio/io_service.hpp>
#include <boost/asio/ip/udp.hpp>
#include <boost/asio/signal_set.hpp>
#include <boost/array.hpp>
#include <boost/bind.hpp>
#include <ctime>
#include <iostream>
#include <syslog.h>
#include <unistd.h>

using boost::asio::ip::udp;

class udp_daytime_server
{
public:
udp_daytime_server(boost::asio::io_service& io_service)
: socket_(io_service, udp::endpoint(udp::v4(), 13))
{
start_receive();
}

private:
void start_receive()
{
socket_.async_receive_from(
boost::asio::buffer(recv_buffer_), remote_endpoint_,
boost::bind(&udp_daytime_server::handle_receive, this, _1));
}

void handle_receive(const boost::system::error_code& ec)
{
if (!ec || ec == boost::asio::error::message_size)
{
using namespace std; // For time_t, time and ctime;
time_t now = time(0);
std::string message = ctime(&now);

boost::system::error_code ignored_ec;
socket_.send_to(boost::asio::buffer(message),
remote_endpoint_, 0, ignored_ec);
}

start_receive();
}

udp::socket socket_;
udp::endpoint remote_endpoint_;
boost::array<char, 1> recv_buffer_;
};

int main()
{
try
{
boost::asio::io_service io_service;

// Initialise the server before becoming a daemon. If the process is
// started from a shell, this means any errors will be reported back to the
// user.
udp_daytime_server server(io_service);

// Register signal handlers so that the daemon may be shut down. You may
// also want to register for other signals, such as SIGHUP to trigger a
// re-read of a configuration file.
boost::asio::signal_set signals(io_service, SIGINT, SIGTERM);
signals.async_wait(
boost::bind(&boost::asio::io_service::stop, &io_service));

// Inform the io_service that we are about to become a daemon. The
// io_service cleans up any internal resources, such as threads, that may
// interfere with forking.
io_service.notify_fork(boost::asio::io_service::fork_prepare);

// Fork the process and have the parent exit. If the process was started
// from a shell, this returns control to the user. Forking a new process is
// also a prerequisite for the subsequent call to setsid().
if (pid_t pid = fork())
{
if (pid > 0)
{
// We're in the parent process and need to exit.
//
// When the exit() function is used, the program terminates without
// invoking local variables' destructors. Only global variables are
// destroyed. As the io_service object is a local variable, this means
// we do not have to call:
//
//   io_service.notify_fork(boost::asio::io_service::fork_parent);
//
// However, this line should be added before each call to exit() if
// using a global io_service object. An additional call:
//
//   io_service.notify_fork(boost::asio::io_service::fork_prepare);
//
// should also precede the second fork().
exit(0);
}
else
{
syslog(LOG_ERR | LOG_USER, "First fork failed: %m");
return 1;
}
}

// Make the process a new session leader. This detaches it from the
// terminal.
setsid();

// A process inherits its working directory from its parent. This could be
// on a mounted filesystem, which means that the running daemon would
// prevent this filesystem from being unmounted. Changing to the root
// directory avoids this problem.
chdir("/");

// The file mode creation mask is also inherited from the parent process.
// We don't want to restrict the permissions on files created by the
// daemon, so the mask is cleared.
umask(0);

// A second fork ensures the process cannot acquire a controlling terminal.
if (pid_t pid = fork())
{
if (pid > 0)
{
exit(0);
}
else
{
syslog(LOG_ERR | LOG_USER, "Second fork failed: %m");
return 1;
}
}

// Close the standard streams. This decouples the daemon from the terminal
// that started it.
close(0);
close(1);
close(2);

// We don't want the daemon to have any standard input.
if (open("/dev/null", O_RDONLY) < 0)
{
syslog(LOG_ERR | LOG_USER, "Unable to open /dev/null: %m");
return 1;
}

// Send standard output to a log file.
const char* output = "/tmp/asio.daemon.out";
const int flags = O_WRONLY | O_CREAT | O_APPEND;
const mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH;
if (open(output, flags, mode) < 0)
{
syslog(LOG_ERR | LOG_USER, "Unable to open output file %s: %m", output);
return 1;
}

// Also send standard error to the same log file.
if (dup(1) < 0)
{
syslog(LOG_ERR | LOG_USER, "Unable to dup output descriptor: %m");
return 1;
}

// Inform the io_service that we have finished becoming a daemon. The
// io_service uses this opportunity to create any internal file descriptors
// that need to be private to the new process.
io_service.notify_fork(boost::asio::io_service::fork_child);

// The io_service can now be used normally.
syslog(LOG_INFO | LOG_USER, "Daemon started");
io_service.run();
syslog(LOG_INFO | LOG_USER, "Daemon stopped");
}
catch (std::exception& e)
{
syslog(LOG_ERR | LOG_USER, "Exception: %s", e.what());
std::cerr << "Exception: " << e.what() << std::endl;
}
}

В любом случае, мне было интересно, является ли это хорошим выбором для запуска и запуска минимального демона (замена кода сервера udp и замена на мой собственный код), или я должен искать другой подход к получению функциональности демона.

Я также запутался в том, где я должен начать свой код, так как последний шаг в этом примере — вызов io_service.run ().

В моем коде будет два потока: один для прослушивания соединения, а другой для обработки ожидающих соединений каждые 10 секунд -> обновления от подключающихся клиентов не имеют критического по времени окна для обновлений и могут даже время от времени пропускаться.

Спасибо.

0

Решение

Если вы ищете быструю и простую реализацию, то это может быть хорошей идеей. По крайней мере, он обеспечивает высокоуровневый способ обработки сигналов, который в противном случае может потребовать довольно подробного понимания механизмов более низкого уровня для получения правильных результатов. Быстрая реализация может выглядеть следующим образом:

void connection_thread_main( bool& running )
{
while ( running )
...
}

int main()
{
...

syslog(LOG_INFO | LOG_USER, "Daemon started");
// Create flag to indicate if daemon is running.  This is used as the
// condition for which the thread's while loop continue.
bool running = true;

// Create threads.
boost::thread_group threads;
threads.create_thread( boost::bind( &connection_thread_main,
boost::ref( running ) ) );
threads.create_thread( boost::bind( &pending_thread_main,
boost::ref( running ) ) );

// This will block the main thread as long as there is work queued into the
// service.  In this case, signals are being waited on asynchronously.
io_service.run();

// On SIGINT or SIGTERM, io_service.stop() is invoked, causing the main
// thread to return from io_service.run().

// Set the running flag to false and wait on the other threads to finish.
running = false;
threads.join_all();

syslog(LOG_INFO | LOG_USER, "Daemon stopped");
}

Есть несколько моментов для рассмотрения:

  • Boost.Asio предоставляет отличные высокоуровневые типы сетевых объектов. Возможно, стоит использовать их вместо того, чтобы иметь дело с типами и деталями более низкого уровня.
  • Хотя асинхронное программирование имеет врожденную сложность, в асинхронной реализации может быть повышение производительности. Поддерживать пулы потоков с Boost.Asio довольно просто.
  • Boost.Asio упрощает обработку сигналов.
  • Если вы решите не использовать Boost.Asio, этот пример является отличным ресурсом о том, как демонизировать процесс.
  • В быстрой реализации я решил сделать решение максимально читабельным. Таким образом, основной поток в основном тратится впустую, так как он только ждет сигналов. Вместо того, чтобы иметь 3 потока, можно поместить один из содержимого потока в цикл в основном и периодически опрос io_service,

    syslog(LOG_INFO | LOG_USER, "Daemon started");
    // Create flag to indicate if daemon is running.  This is used as the
    // condition for which the thread's while loop continue.
    bool running = true;
    
    // Create threads.
    boost::thread_group threads;
    threads.create_thread( boost::bind( &connection_thread_main,
    boost::ref( running ) ) );
    
    for ( ;; )
    {
    // Execute ready to run handlers, but do not block waiting for
    // outstanding handlers to become ready.  When SIGINT or SIGTERM are
    // received, the handler will be ready to run, and ran from the poll
    // call, causing the io_service to stop.
    io_service.poll();
    
    if ( io_service.stopped() ) break;
    
    ... // pending_thread_main's while body content
    }
    
    // Set the running flag to false and wait on the other threads to finish.
    running = false;
    threads.join_all();
    
    syslog(LOG_INFO | LOG_USER, "Daemon stopped");
    
2

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector