|
Boost : |
Subject: Re: [boost] Is the async_read more reliable than async_read_some?
From: hh h (jupiter.hce_at_[hidden])
Date: 2018-12-08 00:05:15
> aynyc_read is essentially implemented by calling
> async_read_some repeatedly, until it fills
> the requested size.
That is exactly the question I am going to ask, if you don't know the
package size to read, you have to call sync_read_some with
max_buffer_size, how does the sync_read_some function know the end of
the message? Obviously, that the end of the message length is smaller
than the max_buffer_size. Is some timeout defined in sync_read_some to
identify the end of the message?
Thanks Steven
On 12/8/18, Steven Watanabe via Boost <boost_at_[hidden]> wrote:
> AMDG
>
> On 12/07/2018 02:44 AM, hh h via Boost wrote:
>> I have been using asio::async_read with protobuf for some time, it is
>> relative easy to use protobuf function SerializeToOstream to attach a
>> packet header and send the packet header along with to protobuf
>> message, with fixed packet header size and message size in the header,
>> I was able to use async_read.
>>
>> But I have to change to use msgpack which I could not find a way like
>> protobuf to attach a packet header to msgpack message. The only way I
>> could do is to use async_read_some, but I am very concerning the
>> remark in the async_read_some document. Appreciate your comments.
>>
>
> How do you identify the end of the message?
> Can you use one of the overloads of async_read
> that takes a completion_condition?
>
>> "The read operation may not read all of the requested number of bytes.
>> Consider using the async_read function if you need to ensure that the
>> requested amount of data is read before the asynchronous operation
>> completes."
>>
>
> aynyc_read is essentially implemented by calling
> async_read_some repeatedly, until it fills
> the requested size.
>
> In Christ,
> Steven Watanabe
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk