wsutil.readData() blocks until desired opcode/frame is received about ws HOT 7 CLOSED

@oguzhane We were experimenting along similar lines and stumbled upon this thread. SetReadDeadline() does not work unfortunately as the micro timeouts leave the connection in a dirty state (partially read bytes maybe) when there's heavy traffic, causing subsequent reads to fail because of malformed messages.

from ws.

Hi @kenfoo,

This is intended behaviour of this method – that is, the word "Data" means exactly what you have discovered – read the data message, not the control.

When using epoll somehow wsutil helpers is not the best way to deal with frames.

from ws.

@kenfoo
maybe, one of the ways below can help you to avoid blocking goroutine.

you could use SetReadDeadline to stop waiting reading data, if it fits your case.

..
netConn.SetReadDeadline(time.Now().Add(50 * time.Millisecond))
data, opCode, err := wsutil.ReadClientData(netConn)
if os.IsTimeout(err) {
  ..
}

Another way could be exposing EWOULDBLOCK error by reading data directly from file descriptor with syscall.Read.

type SysConn struct {
  ..
  fd int
}

func (s SysConn) Read(p []byte) (int, error) {
        ..
	n, err := syscall.Read(s.fd, p)
        ..
	return n, err
}

data, opCode, err := wsutil.ReadClientData(sysConn)
if err  == syscall.EAGAIN {
  ..
}

Would be helpful to check implementation of *netFD.Read to have graceful handling.
see:
https://golang.org/src/net/fd_unix.go
https://golang.org/src/internal/poll/fd_unix.go

from ws.

@knadh I have ended up going for the approach reading data from the file descripter by using syscall.RawConn. However, i have not tested it under high load of traffic yet.
The problem with this approach is it does not work well with crypto/tls since standart Golang TLS implementation does not support event-based mechanism.

from ws.

@oguzhane we tried reading directly from the file descriptor and under high loads, it ran into the same issues with malformed / partial messages.

from ws.

Hi. If it is of any help to anyway, we ended up simply reimplementing what wsutil.readData did, but modified it such that it doesn't block or loop, and instead returns the bytes, the opcode and error in all cases.

from ws.

@kenfoo we attempted this unsuccessfully. It'd be nice if you could share your solution!

from ws.