Im pretty sure I’m correct. It is a socket type not an option on TCP, which
equates to a different protocol. If you use that option you get a SCTP
transport not TCP.
> On Dec 30, 2019, at 4:06 PM, Bruno Albuquerque <b...@gmail.com> wrote:
>
>
> Although I am no expert in the subject, I would doubt this assertion. It is
> there in the socket man page in a Ubuntu machine with no mention of anything
> specific being needed (other than the implicit fact that you need a TCP stack
> that supports it, which should be true for any modern version of Linux
> anyway).
>
>
>> On Mon, Dec 30, 2019 at 12:23 PM Robert Engels <reng...@ix.netcom.com> wrote:
>> 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/D2E3E216-7944-410A-AA96-B1456476A76C%40ix.netcom.com.
