Моего кода выглядит следующим образом:вопросы об использовании async_write сразу после async_read_until
boost::asio::streambuf b1;
boost::asio::async_read_until(upstream_socket_, b1, '@',
boost::bind(&bridge::handle_upstream_read, shared_from_this(),
boost::asio::placeholders::error,
boost::asio::placeholders::bytes_transferred));
void handle_upstream1_read(const boost::system::error_code& error,
const size_t& bytes_transferred)
{
if (!error)
{
async_write(downstream_socket_,
b2,
boost::bind(&bridge::handle_downstream_write,
shared_from_this(),
boost::asio::placeholders::error));
}
else
close();
}
Согласно документации async_read_until, http://www.boost.org/doc/libs/1_55_0/doc/html/boost_asio/reference/async_read_until/overload1.html, После успешной операции async_read_until, то streambuf может содержать дополнительные данные за пределами разделителя. Приложение обычно оставляет эти данные в streambuf для последующей операции async_read_until для проверки.
Я знаю, что streambuf может содержать дополнительные данные за пределами разделителя, но в моем случае он будет записывать эти дополнительные данные (данные за пределами char '@') в downstream_socket_ внутри операции async_write? Или функция async_write достаточно умна, чтобы не писать эти дополнительные данные до следующего вызова функции handle_upstream1_read?
В соответствии с подходами в документации, данные в streambuf сохраняются в IStream первой (станд :: IStream response_stream (& streambuf);) , а затем поместить его в строку, используя зЬй :: GetLine() Funciton.
Нужно ли сначала хранить streambuf в istream, а затем преобразовать его в строку и затем преобразовать обратно в char arrary (чтобы я мог отправить массив char в downstream_socket_) вместо того, чтобы просто использовать async_write для записать данные (до, но не включая разделитель, '@') в downstream_socket_?
Я предпочитаю второй подход, так что мне не нужно делать несколько преобразований по данным. Однако кажется, что что-то не так, когда я попытался сделать второй подход.
Мой идеальный случай, что:
- upstream_socket_ получил хххх @ гггг с помощью async_read_until
- хххх @ записывается в downstream_socket_
- upstream_socket_ получил ZZZZ @ KKKK с помощью async_read_until
- yyyyzzzz @ записывается в downstream_socket_
Кажется, что async_write ope ration все еще записывает данные за пределы разделителя в downstream_socket_. (но я не уверен в этом на 100%)
Я ценю, если кто-нибудь может немного помочь!
Благодарим вас за подробное и подробное объяснение, Таннер. transfer_exactly (n) и streambuf.consume (n) - именно то, что я хочу! Причина, по которой я так долго задерживался, заключается в том, что я попытался использовать единственный символ «@», чтобы действовать как символ конечного тега в моих данных видеопотока, который полностью является дамп-идеей. – hclee
В этом примере используется write(), который я Предположим, что синхронный boost :: asio :: write(), правильно? – Dronz
@Dronz Да. [Аргумент-зависимый поиск] (http://en.wikipedia.org/wiki/Argument-dependent_name_lookup) заставил компилятор выбрать 'boost :: asio :: read()', 'boost :: asio :: write() ',' boost :: asio :: buffers_begin() ', потому что один из их аргументов также находился в пространстве имен' boost :: asio'. Независимо от того, я изменил пример, чтобы быть более явным. –