当我的 Boost::asio tcp 服务器刚刚开始运行时,如何启动"event"(又名 io_service.run() )?



基于boost::asio客户端/服务器关系,只有当服务器线程处于"等待连接"状态时,我才能从服务器程序启动客户端程序。

我的问题是如何获得这种状态的知识?

作为示例使用asio example/serialization链接,并将server.cpp的main函数替换为以下代码:

#include <conio.h>
#include <concrt.h> // wait function
#include <future>
#include <thread>
void server_thread( std::promise<bool>& run )
{ 
    boost::asio::io_service io_service;
    s11n_example::server server(io_service, 123);
    // too early to run.set_value( true );
    io_service.run();
    // too late to run.set_value( true );
}
int main(int argc, char* argv[])
{
    std::promise<bool> run;
    std::thread thrd( server_thread, boost::ref( run ) );
    thrd.detach(); 
    bool launched = run.get_future().get();
    // server is waiting for connection
    // launch the client
    if( launched )
    {
        int rc = system( "start client.exe localhost 123" );
        if( rc )
            std::cerr << "system failed returning " << rc << std::endl ;
    }
    else
        std::cerr << "server_thread failure" << std::endl ;
    std::cout << "hit a key to exit"  ;
    while( !_kbhit() )
        Concurrency::wait( 100 );
    return 0;
}

谢谢,

简而言之,s11n_example::server处于这样一种状态:在构造函数调用完成后,传入的连接将立即排队。


通过定义状态和操作之间的区别,可能更容易理解这一点。状态决定了操作系统可以对对象做什么;应用程序启动执行操作的操作,这些操作可能依赖于状态。例如,当一个套接字处于open状态时,操作系统会将数据排队;read操作检索排队的数据。这同样适用于接受者。当一个acceptor处于listen状态时,操作系统会将连接排队;accept操作将完成连接,并将其从队列中删除。

acceptor[状态]转换()如下:

     .----> [closed] ------.     [closed]:    socket not open
     |                     |     [opened]:    socket open but not listening for
     |                     V                  connections
  close() <------.      open()   [listening]: incoming connections will be
     ^           |         |                  queued until accepted(), causing
     |           |         V                  the connection to be established
[listening]      '---- [opened]
     ^                     |
     |                     |
     '------ listen() <----'

各种重载构造函数将导致acceptor以关闭、打开或侦听状态开始其生命周期。在s11n_example::server的情况下,接收器是用端点构造的,因此这种过载将导致接收器在构造后处于侦听状态。它相当于这样做:

using boost::asio::ip::tcp;
tcp::endpoint endpoint_(tcp::v4(), 123);
tcp::acceptor acceptor_(io_service); // closed state
acceptor.open(endpoint_.protocol()); // opened state
acceptor.bind(endpoint);
acceptor.listen();                   // listening state

因此,promise可以在server构造之后,io_service.run()构造之前设置:

void server_thread(std::promise<bool>& run)
{ 
    boost::asio::io_service io_service;
    s11n_example::server server(io_service, 123);
    // The server's acceptor is in a listening state, so connection attempts
    // will be queued even without the io_service event loop running.  The
    // server also has an outstanding asynchronous accept operation.
    run.set_value(true);
    // Run the service, this will start an asynchronous loop that accepts 
    // connections.
    io_service.run();
}

需要注意的一个微妙之处是Boost。Asio的接受器不提供:

  • 基于反应器的接受连接的操作。因此,不可能检测到连接何时准备好接受(即连接正在排队等待接受)。
  • 检测acceptor是否处于监听状态的高级方法。然而,这可以通过查询接收方的native_handle来完成。例如,使用getsockopt()获取SOL_SOCKET/SO_ACCEPTCONN的值。

最新更新