Oh, and I don’t think SCTP is natively supported on Windows yet.
So your interoperability May vary...
> On Dec 30, 2019, at 4:17 PM, Robert Engels <reng...@ix.netcom.com> wrote:
>
>
> 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/DEFCD97C-52C4-4ACC-AB57-C8F06F7A47E8%40ix.netcom.com.
