But, to complicate things, you can create what is basically a TCp
connection with packet boundaries using SOCK_SEQPACKET (as opposed to
SOCK_STREAM or SOCK_DGRAM).
On Mon, Dec 30, 2019 at 9: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
> <https://groups.google.com/d/msgid/golang-nuts/7e468329-2488-460c-9419-b4c55857b1eb%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAEd86TxqRRML-HDe7H8vESCTBOhBV3c%3DfY0gamEZrrb6XKgfzA%40mail.gmail.com.
