That option requires proprietary protocols not standard tcp/udp.
> On Dec 30, 2019, at 12:04 PM, Bruno Albuquerque <b...@gmail.com> wrote:
>
>
> 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.
>
> --
> 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.
--
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/18B10B81-7E60-468D-8BDC-6C65B9884473%40ix.netcom.com.
