我正在尝试弄清楚套接字是如何工作的。我使用boost asio库,但我仍然没有完全理解一些点:
假设 TCP 连接已成功建立并且套接字已打开。现在我想“向服务器发出请求”并发送某条数据:
template<typename P>
void send_with_payload(Socket& socket, const P& payload)
{
// Общий размер запроса
const auto len = sizeof(Header) + sizeof(P);
// Заголовок
buffer_copy(buffer_->prepare(sizeof(Header)), boost::asio::buffer(&header_, sizeof(Header)));
buffer_->commit(sizeof(Header));
// Полезная нагрузка
buffer_copy(buffer_->prepare(sizeof(P)), boost::asio::buffer(&payload, sizeof(P)));
buffer_->commit(sizeof(P));
// Писать в сокет (покуда не будет записано всё)
boost::system::error_code error;
write(socket, *buffer_, boost::asio::transfer_exactly(len), error);
if(error.failed())
{
buffer_->consume(buffer_->size());
throw std::runtime_error(error.message());
}
buffer_->consume(len);
}
而此时问题就出现了:
该线boost::asio::transfer_exactly本质上是一个终止条件。这意味着对套接字的写入将继续,直到“写入”指定的字节数。但写下来到底意味着什么呢?这是否意味着它已在另一面被读取?而且还没读完,流量就被堵住了? (这正是实践所表明的,但我不确定这种行为是否正确)或者另一侧根本不需要同时读取,数据仍然会发送,但会被“暂停”通过套接字中的服务器(对它们的诽谤,你可以随时执行,并且客户端不会等待服务器读取它们)?或者也许这两种选择都是可能的?
第二点(服务器端)。鉴于录音只录制过一次,“读几次”的正确性如何?例如:
首先,我们从套接字读取数据的第一部分:
void receive(Socket& socket
, const TypeBits& types
, const Operation& op = Operation::O_UNKNOWN)
{
// Читаем ТОЛЬКО заголовок (чтение прекращается когда получен его размер)
boost::system::error_code error;
read(socket, *buffer_, boost::asio::transfer_at_least(sizeof(Header)), error);
auto* data = const_cast<void*>(buffer_->data().data());
header_ = *static_cast<Header*>(data);
buffer_->consume(sizeof(Header));
header_received_ = true;
}
我们第二次读取剩余部分(根据第一次读取时获得的数据,确定剩余部分的大小)
template<typename P>
class RequestWithPayload final : public Request
{
public:
explicit RequestWithPayload(Request* base)
: base_(base)
{}
~RequestWithPayload() override = default;
void receive_payload(Socket& socket) override
{
// Читаем "полезную нагрузку" (чтение завершается когда получен размер полезной нагрузки)
boost::system::error_code error;
read(socket, *buffer_, boost::asio::transfer_exactly(sizeof(P)), error);
auto* data = const_cast<void*>(buffer_->data().data());
payload_ = *static_cast<P*>(data);
buffer_->consume(sizeof(P));
}
const P& payload()
{
return payload_;
}
protected:
P payload_;
Request* base_;
};
我想做的事情(一次写入 - 两次读取)不起作用(服务器在第二次读取时挂起并永远等待),我不确定这是否是因为它对于套接字来说从根本上来说是错误的(每次我们写,我们立即需要一切并阅读),或出于其他原因。
我将很高兴收到详细的答复。
PS感谢评论,我发现了一个错误,导致服务器在第二次读取时挂起。阅读时,一切都是关于至少transfer_at_least。有必要读取固定且精确的大小(transfer_exactly)。但总的来说,提出的问题仍然是相关的:
- 当流被阻塞时 - 要解除阻塞,是否需要第二方参与(读取发送的数据)?
- 如果是,具体是哪一个? (阅读所有内容/阅读一些内容/尝试阅读)
- 如果不是,解除线程阻塞的标准是什么,函数在什么时候返回控制权?
严格来说,不一定。在某些情况下,接收方根本无法执行任何操作,因为数据尚未到达其节点(例如,流量限制器将其暂停了很短的时间,或者路由器切换到备份线路,并且 TCP 正在等待)以便重传数据包)。
不仅要读一些东西,而且要读很多东西。粗略地说,如果在发送请求时流在第一个字节上被阻塞,那么如果第二方读取的数据仅足以满足标头,那么您将不会注意到流可能被解除阻塞并再次阻塞,或者可能没有畅通无阻(取决于实现,加上上面的注意事项)。
严格来说,相应的操作系统调用(send())成功接收了所有数据。
不。为了让另一方确认他已阅读某些内容和/或理解他所阅读的内容,他必须发送对此的明确确认。
transfer_at_least()可能更高效,因为在成功的重负载情况下,它减少了操作系统调用的数量。那些。如果操作系统不仅可以立即将标头传输到缓冲区,还可以立即将所有内容传输到缓冲区,那么为什么不呢?你只需要正确使用它(也许操作系统,为了不起床,返回了3.62记录)。 😉