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.
