Your environment.

• Version: Release or SHA
• Browser: include version
• Other Information - stacktraces, related issues, suggestions how to fix, links for us to have context

What did you do?

A working example of what I'm trying to do is in this gist

I have some potentially large payloads I want to be able to transmit with this package. I say potentially, because the payloads are unbounded.

The way I've done this is via a pretty naive fragmenter; since the maximum datagram size is 64k and we have tls overheads, split the data in chunks of slighty-smaller-than-64k, and send them on. The server side of this, as implemented with this package, works fine; I've verified this with wireshark as I was trying to debug this issue.

The problem is when I come to receive the data, also with this package. Setting a buffer of slighty-smaller-than-64k returns an io.EOF. Not a subset of data, but an EOF. Through trial and error I figured out that I was able to roughly read 8k at a time. Anything larger and I get nothing.

I found this in the repo, which looks precisely like what I'm hitting.

I guess, then, what I'm asking is:

1. Does that 8k come from somewhere specific? I'm more than happy to be told I don't know anything about networking and that 8k is a magic number than can't be tweaked
2. If not, should it be made a var and settable in code? Perhaps via the dtls.Config struct?
3. If not, then should the maximum size we can send be set to 8k too?

I'm also, again, more than happy to be told I'm using the package wrong and that there's a smarter way for fragmenting data.

What did you expect?

To be able to receive packets of more than 8k, or for this to be documented somewhere.

Or, if it is documented, perhaps either clearer, or for the server to enforce the same limit.

What happened?

I was unable to, and in fact received an io.EOF instead.