- android - RelativeLayout 背景可绘制重叠内容
- android - 如何链接 cpufeatures lib 以获取 native android 库?
- java - OnItemClickListener 不起作用,但 OnLongItemClickListener 在自定义 ListView 中起作用
- java - Android 文件转字符串
我正在编写基于 boost asio 的代理服务器。在负责接受从浏览器到代理服务器的传入连接的代码部分,我面临着我不完全理解的行为。
所以 - 我正在使用下一个构造函数创建接受器对象:
_acceptor(_io_service, boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), port ), true)
从这里开始收听 (start_accept):
_new_connection.reset(new connection(*_io_services.front(), _connection_id));
_acceptor.async_accept(_new_connection->get_socket(),
boost::bind(&server::handle_accept, this,
boost::asio::placeholders::error));
和handle_accept
if (!error) {
_new_connection->start();
}
// continue waiting for incoming connections
start_accept();
一般来说,我接受传入连接的代码与 HTTP Server 2 中的相同。例子
只有当第一个传入连接未关闭时才会出现问题,然后第二个传入连接将排队等待,直到第一个传入连接关闭。
根据这两个答案: boost::asio acceptor reopen and async read after EOF
How to launch an "event" when my Boost::asio tcp server just start running ( AKA io_service.run() )?
acceptor 对象会将所有传入的连接添加到队列中,并且不会接受它们,直到挂起的连接不会被关闭。
我想实现对所有传入连接的立即处理——这样它们就不会在接受者的队列中挂起,到目前为止我还没有找到任何解决方案。
你能帮我看看,什么是正确的实现方式?
连接->start()函数
void
connection::start() {
_bsocket.async_read_some(boost::asio::buffer(_bbuffer),
boost::bind(&connection::handle_browser_read_headers,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred
));
}
Graphical representation更新: boost asio 日志
@asio|1368460995.389629|0*1|socket@00CCFBE4.async_accept
@asio|1368461003.855113|>1|ec=system:0
@asio|1368461003.855113|1*2|socket@00E26850.async_receive
@asio|1368461003.855113|>2|ec=system:0,bytes_transferred=318
@asio|1368461003.856113|1*3|socket@00CCFBE4.async_accept
@asio|1368461003.856113|<1|
@asio|1368461003.856113|2*4|resolver@00E268D8.async_resolve
@asio|1368461003.856113|<2|
@asio|1368461003.866114|>4|ec=system:0,...
@asio|1368461003.866114|4*5|socket@00E26894.async_connect
@asio|1368461003.868114|<4|
@asio|1368461004.204133|>5|ec=system:0
@asio|1368461004.204133|5*6|socket@00E26894.async_send
@asio|1368461004.204133|<5|
@asio|1368461004.204133|>6|ec=system:0,bytes_transferred=302
@asio|1368461004.204133|6*7|socket@00E26894.async_receive
@asio|1368461004.204133|<6|
@asio|1368461004.613156|>7|ec=system:0,bytes_transferred=16384
@asio|1368461004.613156|7*8|socket@00E26850.async_send
@asio|1368461004.614157|<7|
@asio|1368461004.614157|>8|ec=system:0,bytes_transferred=16384
@asio|1368461004.614157|8*9|socket@00E26894.async_receive
@asio|1368461004.614157|<8|
@asio|1368461004.614157|>9|ec=system:0,bytes_transferred=1946
@asio|1368461004.614157|9*10|socket@00E26850.async_send
@asio|1368461004.614157|<9|
@asio|1368461004.614157|>10|ec=system:0,bytes_transferred=1946
@asio|1368461004.614157|10*11|socket@00E26894.async_receive
@asio|1368461004.614157|<10|
@asio|1368461004.618157|>11|ec=system:0,bytes_transferred=14080
@asio|1368461004.618157|11*12|socket@00E26850.async_send
@asio|1368461004.619157|<11|
@asio|1368461004.619157|>12|ec=system:0,bytes_transferred=14080
@asio|1368461004.619157|12*13|socket@00E26894.async_receive
@asio|1368461004.619157|<12|
@asio|1368461019.248994|>13|ec=asio.misc:2,bytes_transferred=0
@asio|1368461019.248994|13|socket@00E26894.close
@asio|1368461019.248994|13|socket@00E26850.close
@asio|1368461019.248994|<13|
@asio|1368461019.253994|0|resolver@00E268D8.cancel
@asio|1368461019.253994|>3|ec=system:0
@asio|1368461019.253994|3*14|socket@00E32688.async_receive
@asio|1368461019.254994|3*15|socket@00CCFBE4.async_accept
@asio|1368461019.254994|<3|
@asio|1368461019.254994|>14|ec=system:0,bytes_transferred=489
@asio|1368461019.254994|14*16|resolver@00E32710.async_resolve
@asio|1368461019.254994|<14|
@asio|1368461019.281995|>16|ec=system:0,...
@asio|1368461019.281995|16*17|socket@00E326CC.async_connect
@asio|1368461019.282996|<16|
@asio|1368461019.293996|>17|ec=system:0
@asio|1368461019.293996|17*18|socket@00E326CC.async_send
@asio|1368461019.293996|<17|
@asio|1368461019.293996|>18|ec=system:0,bytes_transferred=470
@asio|1368461019.293996|18*19|socket@00E326CC.async_receive
@asio|1368461019.293996|<18|
@asio|1368461019.315997|>19|ec=system:0,bytes_transferred=11001
@asio|1368461019.315997|19*20|socket@00E32688.async_send
@asio|1368461019.349999|<19|
@asio|1368461019.349999|>20|ec=system:0,bytes_transferred=11001
@asio|1368461019.349999|20|socket@00E326CC.close
@asio|1368461019.349999|20|socket@00E32688.close
@asio|1368461019.349999|<20|
@asio|1368461019.349999|0|resolver@00E32710.cancel
我发现接受器的行为取决于我用于从服务器套接字读取数据的函数。连接类从浏览器读取数据,修改请求url,连接到主机并发送请求,然后从服务器读取响应并将其写回浏览器。所以在我需要读取服务器主体的那一刻——我使用这个函数
_ssocket.async_read_some(boost::asio::buffer(_sbuffer),
boost::bind(&connection::handle_server_read_body,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred
));
如果服务响应 header 中未指定内容长度,我将一直读到 EOF。如果调用了 async_read_some 函数并且套接字上没有更多数据可读,它会等待约 15 秒,然后 EOF 才会被引发。 acceptor 不会接受这 15 秒内的所有新传入连接。
但是如果我使用 async_read 的另一种变体 -
boost::asio::async_read(_ssocket, boost::asio::buffer(_sbuffer),
boost::bind(&connection::handle_server_read_body,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred
));
传入的连接被接受得很好。但是它 boost::asio::async_read 工作起来有点慢,它正在等待从套接字读取一堆数据并且在读取数据之前不会调用处理程序,所以 - 我想我会指定 transfer_at_least
boost::asio::async_read(_ssocket, boost::asio::buffer(_sbuffer), boost::asio::transfer_at_least(1),
boost::bind(&connection::handle_server_read_body,
shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred
));
是的,它变得更好了 - 但接受新连接的问题返回:/
async_read_some 和 boost::asio::async_read 之间的真正区别是什么 - 感觉好像有什么东西被阻塞了。
最佳答案
我不知道这是否有帮助,但在我的服务器中,我将以下内容用于 session 的读取请求:
boost::asio::async_read( socket(), boost::asio::buffer( _incoming ),
boost::asio::transfer_at_least( 1 ),
boost::bind( &server_class::handle_read, shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred ) );
然后我将收到的所有内容转储到解析器中以确保它是正常的(处理状态等)。
否则,我相信我正在做你正在做的一切,基于我在这里看到的。
如果这可行,那么 asio 的行为似乎不直观。
关于c++ - boost::asio::acceptor - 在旧连接仍然打开时接受新的传入连接,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16521070/
我已经使用 boost 实现了一个 SocketServer。此 SocketServer 旨在按如下方式工作: 在一定时间内接受连接 超时后停止处理套接字 这是我的代码: ServerSocket:
关闭。这个问题需要debugging details .它目前不接受答案。 编辑问题以包含 desired behavior, a specific problem or error, and th
我正在使用 C++ boost asio 库,我在其中监听套接字上的新连接。获得连接后,我处理请求,然后循环监听另一个套接字上的新连接。 while (true) { tcp::socket
我正在编写基于 boost asio 的代理服务器。在负责接受从浏览器到代理服务器的传入连接的代码部分,我面临着我不完全理解的行为。 所以 - 我正在使用下一个构造函数创建接受器对象: _accept
在尝试运行我的 config.ru 时,我遇到了一个我似乎无法调试的奇怪错误,称为“无接受器”错误。 完整错误信息: eventmachine.rb:572:in `start_tcp_server'
目标: 编译“Acceptor”程序(服务器)。完成后,编译一个“启动器”(客户端),然后打印一个简单的输出,以确认两个应用程序正在相互通信(我已经阅读了 QuickFix 文档并且大部分理解的要求)
使用 QuickFIX/J 1.6.3 我的 QuickFIX/J 接受器出现这种奇怪的行为,我完全不知道为什么。我的接受者正在发送一个测试请求,期待一个心跳,发起者向我发送一个心跳,但我的接受者无论
我试图将成员函数作为 AcceptHandler 传递给 boost::asio 的 async_accept() 方法。我收到一个编译错误: AcceptHandler type requireme
我对 Boost 有点陌生,但我正在尝试创建一个服务器,它可以在给定端口上接受来自客户端的连接。该服务器还应该能够在同一端口上写入客户端。 但是,当我尝试使用 acceptor_.bind() 来实现
我将我的项目(node.js + mongodb)从 Openshift v2 切换到 v3。此外,我在我的项目中使用 v3 的 Starter 版本,并在所有配置中使用 Web 控制台。 部署导致失
我正在尝试并排创建一个 tcp::acceptor 和一个 libtorrent::session,但是在等待来自std::cin。如堆栈跟踪所示,访问冲突发生在 Boost IOCP 实现中。 Wi
我最近开始在一个项目中使用 Boost.Asio,想知道是否有人知道将新创建的套接字的所有权转移到 tcp::acceptor::async_accept 的干净解决方案,这将反过来转移这个所有权接受
我有一个作为守护程序运行的 Sinatra 应用程序,使用 Apache 端口转发在端口 80 和端口 7655 之间进行调解。这在过去一直运行良好。今天,不太好。我不明白为什么。 问题:sudo r
在 Multi-Paxos 算法中,从接受者的角度考虑这个消息流: 接收:准备(N) 回复: promise (N,空) 接收:接受!(N,V1) 回复:接受(N,V1) 接收:接受!(N+1,V2)
我想用 Hunchentoot 的 easy-ssl-acceptor在 LispWorks 中。但是,我看到此类接受器具有以下功能语法 #-:hunchentoot-no-ssl . 这个功能确实存
我正在尝试像这样使用 boost::asio::local::stream_protocol::acceptor : accept_(getIOService(), endpoint_) 这个调用返回
我已经实现了启动 tcp 连接的简单 boost::asio 程序。它在 linux 上运行完美(ubuntu 12.04,boost 1_48,gcc 4.6.4),但不是在 Win7 上(boos
我从 pthread_mutex_lock 得到段错误,这是我的回溯: Program received signal SIGSEGV, Segmentation fault. 0x00007
我在 nginx 上部署了一个 rails 应用程序,使用 capistrano(rails 4、ruby 2.1.2、thin 1.6.2、capistrano 2.1.5)进行瘦身。我通过瘦启动命
我一直在尝试使用 tcp::acceptor 创建一个非阻塞的 TCP 服务器。我在使用 BSD 套接字和 C(++) 之前完成了此操作,但无法使用 boost 设置非阻塞 I/O。 C(++): #
我是一名优秀的程序员,十分优秀!