[go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[jake6502]

On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
>
> The Conn and UDPConn Read methods look like io.Reader Read methods, but 
> there is no explicit claim that Conn is an io.Reader. Are the Read 
> methods of these two types identical in behaviour to io.Reader? 
>
 
I can not say definitively, but on unix, UDPConn.Read() is actually 
net.conn.Read() , whch 
calls net.netFD.Read(), which in turn calls poll.FD.Read() 
. You can see there 
in the code:

// Read implements io.Reader.

The windows and plan9 versions also land in Read() functions that have the same 
comment. So it seems to me that UDPConn.Read() is an io.Reader. Of course, that 
only means that it conforms to the requirements of io.Reader 
.

Specifically, are the reads allowed to fill the buffer with arbitrary 
> numbers of bytes in 0 <= len(p) <= n? 
>
 
Yes, according to io.Reader  docs, an 
implementation may do that. Looking at the actual implementations of the 
poll.FD.Read functions, I would say that it seems like they will always 
return the full UDP packts, if it is <= len(p). A full search of the 
relevant platform docs would be required to say definitively. 


> Also, can UPDConn.Read fill the buffer with more than one packet if the 
> buffer would accommodate that? (I am guessing yes, and that if this is 
> important then the ReadFrom method should be used). 
>
>
It looks to me like this will in fact read one packet at a time on amd64 
unix. The function will return after a single successful syscall(SYS_READ) 
which, IIUC will just be one packet for UDP. Since there is no actual 
documentation guaranteeing this, you would have to look at the source code, 
and platform docs, for every platform you care about to be 100% sure. 
However, if it did not work this way, it would make UDP programming very 
hard, or even impossible. So I think it very likely. 
 

> thanks 
> Dan 
>


 

-- 
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/4de7bd5d-5ee5-4ca1-99c9-bba25556134d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Thanks, Jake. This was very helpful.

On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote:
> On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
> > 
> > 
> > The Conn and UDPConn Read methods look like io.Reader Read methods,
> > but 
> > there is no explicit claim that Conn is an io.Reader. Are the Read 
> > methods of these two types identical in behaviour to io.Reader? 
> > 
>  
> I can not say definitively, but on unix, UDPConn.Read() is actually 
> net.conn.Read() ,
> whch 
> calls net.netFD.Read(), which in turn calls poll.FD.Read() 
> . You can see
> there 
> in the code:
> 
> // Read implements io.Reader.
> 
> The windows and plan9 versions also land in Read() functions that
> have the same comment. So it seems to me that UDPConn.Read() is an
> io.Reader. Of course, that only means that it conforms to the
> requirements of io.Reader .
> 
> Specifically, are the reads allowed to fill the buffer with
> arbitrary 
> > 
> > numbers of bytes in 0 <= len(p) <= n? 
> > 
>  
> Yes, according to io.Reader  docs,
> an 
> implementation may do that. Looking at the actual implementations of
> the 
> poll.FD.Read functions, I would say that it seems like they will
> always 
> return the full UDP packts, if it is <= len(p). A full search of the 
> relevant platform docs would be required to say definitively. 
> 
> 
> > 
> > Also, can UPDConn.Read fill the buffer with more than one packet if
> > the 
> > buffer would accommodate that? (I am guessing yes, and that if this
> > is 
> > important then the ReadFrom method should be used). 
> > 
> > 
> It looks to me like this will in fact read one packet at a time on
> amd64 
> unix. The function will return after a single successful
> syscall(SYS_READ) 
> which, IIUC will just be one packet for UDP. Since there is no
> actual 
> documentation guaranteeing this, you would have to look at the source
> code, 
> and platform docs, for every platform you care about to be 100%
> sure. 
> However, if it did not work this way, it would make UDP programming
> very 
> hard, or even impossible. So I think it very likely. 
>  
> 
> > 
> > thanks 
> > Dan 
> > 
> 
>  
> 

-- 
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/1557783886.17937.0.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[Ian Lance Taylor]

On Mon, May 13, 2019 at 2:45 PM Dan Kortschak  wrote:
>
> Thanks, Jake. This was very helpful.

It does seem that the docs in this area should be improved.  Alas.

Ian


> On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote:
> > On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
> > >
> > >
> > > The Conn and UDPConn Read methods look like io.Reader Read methods,
> > > but
> > > there is no explicit claim that Conn is an io.Reader. Are the Read
> > > methods of these two types identical in behaviour to io.Reader?
> > >
> >
> > I can not say definitively, but on unix, UDPConn.Read() is actually
> > net.conn.Read() ,
> > whch
> > calls net.netFD.Read(), which in turn calls poll.FD.Read()
> > . You can see
> > there
> > in the code:
> >
> > // Read implements io.Reader.
> >
> > The windows and plan9 versions also land in Read() functions that
> > have the same comment. So it seems to me that UDPConn.Read() is an
> > io.Reader. Of course, that only means that it conforms to the
> > requirements of io.Reader .
> >
> > Specifically, are the reads allowed to fill the buffer with
> > arbitrary
> > >
> > > numbers of bytes in 0 <= len(p) <= n?
> > >
> >
> > Yes, according to io.Reader  docs,
> > an
> > implementation may do that. Looking at the actual implementations of
> > the
> > poll.FD.Read functions, I would say that it seems like they will
> > always
> > return the full UDP packts, if it is <= len(p). A full search of the
> > relevant platform docs would be required to say definitively.
> >
> >
> > >
> > > Also, can UPDConn.Read fill the buffer with more than one packet if
> > > the
> > > buffer would accommodate that? (I am guessing yes, and that if this
> > > is
> > > important then the ReadFrom method should be used).
> > >
> > >
> > It looks to me like this will in fact read one packet at a time on
> > amd64
> > unix. The function will return after a single successful
> > syscall(SYS_READ)
> > which, IIUC will just be one packet for UDP. Since there is no
> > actual
> > documentation guaranteeing this, you would have to look at the source
> > code,
> > and platform docs, for every platform you care about to be 100%
> > sure.
> > However, if it did not work this way, it would make UDP programming
> > very
> > hard, or even impossible. So I think it very likely.
> >
> >
> > >
> > > thanks
> > > Dan
> > >
> >
> >
> >
>
> --
> 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/1557783886.17937.0.camel%40kortschak.io.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAOyqgcXbyAt4zfYSqPGH-v%3DspTPykv%3D_4ByPA6Q8nhddob3cxg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: guarantees on net.Conn and net.UDPConn Read

[Dan Kortschak]

Yes. There's also the unfortunate collision with io.ReaderFrom's method
name which is directionally opposite to net.PacketConn's ReadFrom. This
is unfixable because of Go1.

Dan

On Mon, 2019-05-13 at 15:14 -0700, Ian Lance Taylor wrote:
> On Mon, May 13, 2019 at 2:45 PM Dan Kortschak 
> wrote:
> > 
> > 
> > Thanks, Jake. This was very helpful.
> It does seem that the docs in this area should be improved.  Alas.
> 
> Ian
> 
> 
> > 
> > On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote:
> > > 
> > > On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote:
> > > > 
> > > > 
> > > > 
> > > > The Conn and UDPConn Read methods look like io.Reader Read
> > > > methods,
> > > > but
> > > > there is no explicit claim that Conn is an io.Reader. Are the
> > > > Read
> > > > methods of these two types identical in behaviour to io.Reader?
> > > > 
> > > I can not say definitively, but on unix, UDPConn.Read() is
> > > actually
> > > net.conn.Read()  > > 63>,
> > > whch
> > > calls net.netFD.Read(), which in turn calls poll.FD.Read()
> > > . You can
> > > see
> > > there
> > > in the code:
> > > 
> > > // Read implements io.Reader.
> > > 
> > > The windows and plan9 versions also land in Read() functions that
> > > have the same comment. So it seems to me that UDPConn.Read() is
> > > an
> > > io.Reader. Of course, that only means that it conforms to the
> > > requirements of io.Reader .
> > > 
> > > Specifically, are the reads allowed to fill the buffer with
> > > arbitrary
> > > > 
> > > > 
> > > > numbers of bytes in 0 <= len(p) <= n?
> > > > 
> > > Yes, according to io.Reader 
> > > docs,
> > > an
> > > implementation may do that. Looking at the actual implementations
> > > of
> > > the
> > > poll.FD.Read functions, I would say that it seems like they will
> > > always
> > > return the full UDP packts, if it is <= len(p). A full search of
> > > the
> > > relevant platform docs would be required to say definitively.
> > > 
> > > 
> > > > 
> > > > 
> > > > Also, can UPDConn.Read fill the buffer with more than one
> > > > packet if
> > > > the
> > > > buffer would accommodate that? (I am guessing yes, and that if
> > > > this
> > > > is
> > > > important then the ReadFrom method should be used).
> > > > 
> > > > 
> > > It looks to me like this will in fact read one packet at a time
> > > on
> > > amd64
> > > unix. The function will return after a single successful
> > > syscall(SYS_READ)
> > > which, IIUC will just be one packet for UDP. Since there is no
> > > actual
> > > documentation guaranteeing this, you would have to look at the
> > > source
> > > code,
> > > and platform docs, for every platform you care about to be 100%
> > > sure.
> > > However, if it did not work this way, it would make UDP
> > > programming
> > > very
> > > hard, or even impossible. So I think it very likely.
> > > 
> > > 
> > > > 
> > > > 
> > > > thanks
> > > > Dan
> > > > 
> > > 
> > > 
> > --
> > 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/1557783886.17937.0.camel%40kortschak.io.
> > For more options, visit https://groups.google.com/d/optout.

-- 
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/1557791271.21310.94.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.