ReadAll reads until buffer length or EOF.
> On Dec 30, 2019, at 11:04 AM, Jake Montgomery <jake6...@gmail.com> wrote:
>
>
> It sounds like maybe you have some misconceptions about TCP. It is a stream
> protocol, there are no data boundaries that are preserved. If send 20 bytes
> via TCP in a single call, it is likely that those 20 will arrive together at
> the client. But it is NOT guaranteed. It is perfectly legitimate for 10 bytes
> to arrive first, then the next 10 sometime later. Obviously this is unlikely
> with only a few bytes, but becomes more likely as the size of the Write
> grows. Until the connection is closed, you never know if there is more data
> coming. So it may seem that there is a 1:1 correlation between conn.Write()
> and conn.Read(), but you can not count on it.
>
> To answer you specific question, conn.Read() will return when it has filled
> up the buffer provided, or there is no more data ready to be read at that
> moment. ReadAll() will wait until EOF. Given that TCP is a stream, as I
> described above, it is still unclear what you hope to have happen without
> knowing more about the specific data being transmitted, and what you wan to
> do with it on the client side.
>
>
>
>
>> On Sunday, December 29, 2019 at 10:20:39 AM UTC-5, Ron Wahler wrote:
>> Jake,
>>
>> Thanks for the reply. Csrc.Read is what I was referring to as the connection
>> standard read, should not have used the words "standard read" sorry about
>> that. The problem I am trying to solve is reading an unknown amount of byte
>> data. I am trying to understand what triggers the Csrc.Read(buf) to return
>> when I send say 3 bytes to it with a client, I also keep the connection open
>> and send a few bytes of characters with the netcat tool, the Csrc.Read
>> returns, but the snip it below that with ReadAll does not return. I am
>> trying to understand the underlying behavior of what triggers a return with
>> the data in these two calls ?
>>
>> on this read :
>>
>> Csrc net.Conn
>>
>>
>> buf := make([]byte, 1024*32)
>>
>> // READ FROM CLIENT
>>
>> nBytes, err := Csrc.Read(buf)
>>
>>
>>
>> Csrc.Read(buf) returns with a few bytes that I send to it. It does not
>> wait for the entire allocated buf size to return. This works great, but I am
>> looking for a way to not preallocate a large buffer.
>>
>>
>>
>> I am prototyping with ReadAll, see the following snip it, but when I send a
>> few bytes to this call with a client, it does not return. The documentation
>> is saying it may be looking for an EOF which I do not send.
>>
>>
>>
>> buf, read_err := ioutil.ReadAll(Csrc)
>>
>>
>>
>>
>>
>> thanks,
>>
>> Ron
>>
>>
>>
>>
>>
>>
>>> On Friday, December 27, 2019 at 5:11:42 PM UTC-7, Ron Wahler wrote:
>>> I am looking for a net.conn standard read that would return a data buffer
>>> the exact size of the read. I am trying to read an unknown amount of byte
>>> data from the connection. With the read i am using I am required to
>>> pre-allocate a buffer and pass that buffer to the read. I am looking for a
>>> read that works more like the ReadString , but is for a byte slice.
>>>
>>> // I want something similar to this read that returns the read string into
>>> the message string.
>>> message, err := bufio.NewReader(ServerConn).ReadString('\n')
>>>
>>> if ( err != nil ){
>>>
>>> fmt.Println("RELAY: ERROR: Reg Message read err:",
>>> err)
>>>
>>> return
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>> // had to preallocate a buffer, but I want a read to return me a buffer so
>>> I don't have to guess how big to make it.
>>>
>>> buf := make([]byte, 1024*32)
>>>
>>> // READ FROM CLIENT
>>>
>>> nBytes, err := Csrc.Read(buf)
>>>
>>>
>>>
>>>
>>>
>>> Is this not possible, I have not seen any examples that would indicate that
>>> there is a standard library that would do something like what I am looking
>>> for.
>>>
>>>
>>>
>>> thanks,
>>>
>>> Ron
>>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/7e468329-2488-460c-9419-b4c55857b1eb%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/C505C73A-325C-4AEA-A564-326590AD97E4%40ix.netcom.com.
