That brings up a problem I have with the way godoc is generated/provided. If you go to the TCPConn SetReadDeadline function, it states “implements the Conn SetReadDeadline method”, with no way of referencing the documentation for Conn.SetReadDeadline, in fact, no way of even getting to the Conn interface… who knows what Conn is ??? Assume it is a Conn returned by Dial? How do you determine this?
Furthermore, it is not completely specified, meaning if the read timeout occurs, and some data was read, is it discarded? will it be returned with the next read (if any)? Doesn’t say... Maybe I am looking at it wrong, but I think Go’s “simplicity” cannot be extended to the specifications, especially when dealing with low-level networking, api, etc. It makes it very difficult to use, and be able to guarantee it will work the same on all platforms - hurting the portability. > On Oct 1, 2018, at 2:01 PM, Ian Lance Taylor <i...@golang.org> wrote: > > On Sun, Sep 30, 2018 at 6:41 PM, Dan Kortschak > <dan.kortsc...@adelaide.edu.au> wrote: >> >> I have been translating some C socket networking code (not my main area >> of expertise) and there is something that I don't see a way to do with >> net.TCPConn. >> >> The original code sets a revc timeout using >> >> ``` >> setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &timeout, sizeof(timeout)); >> ``` >> >> Short of messing around with the fd and using syscall.SetsockoptTimeval >> (or unix.SetsockoptTimeval) which seems like overkill, is there a >> sensible way to do this or is it omitted because it is not a useful >> thing to do? > > As you know, Go's net package uses deadlines rather than timeouts. We > made this choice because timeouts are inherently ambiguous when > reading more than 1 byte from a TCP connection: does the timeout refer > to reading all the requested data, or does it refer to reading a > single byte, or does it refer to the amount of time between each byte > that arrives? And in the modern era this has to be considered in the > context of slowloris attacks. Rather than try to sort out what people > might want, we just use a deadline, which is always clear. > > The best approach for your case is going to be to figure out what the > code you are porting actually wants. > > Ian > > -- > 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. > 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. For more options, visit https://groups.google.com/d/optout.
