I don't understand what you are trying to do, but I guess, if you want to read and write a bit large chunk per socket IO system call, you need to modify the kernel implementation. FWIW, there are sort of soft and hard limits; see kern.ipc.sorecvmincopy and friends.

See https://github.com/opensource-apple/xnu/blob/10.11/bsd/kern/uipc_socket.c#L2957. Closing, there is nothing we can do about it.

I want to encode large data chunks using binary encoding and send/receive them via network. This seems to be not possible at the moment. Would it be possible for Go(net or encoding/binary) to break message down to 2GB chunks during reads/writes. Maybe ReadFull can be relaxed and made incremental ?

You could do that yourself. The data sizes you are dealing with are unreasonably large for a single operation, and if you expect to handle items like that you should design your software not to lock down so much memory in a single call. Use a streaming design instead.

In the os package we cap reads and writes at 1GB on Darwin and FreeBSD. See issue #7812 and https://golang.org/cl/89900044. This issue is essentially the same as #7812, only for the net package rather than the os package, and we could fix it the same way. Reopening.

@ianlancetaylor,

Just for clarification, I'm still unclear what you mean by "the same way", because unlike IO operation to filesystem, there are various characteristics of the underlying protocols for socket IO operation. Are you suggesting to introduce sort of chunk split layer not only into read/write on byte stream protocols but into datagram protocols? Or just for byte stream protocols?

That's true, it seems fairly clear that we should only do it for TCP, not UDP. Fortunately, I think we have that information in the Read and Write methods in net/fd_unix.go.

I remain unconvinced of the value of lifting the limit.

CL https://golang.org/cl/31584 mentions this issue.