We've been hitting a problem with sending frames over UDP that over 50k bytes despite writing a NWProtocolFramer based on the code in this thread The error is coming from the stack with:
nw_protocol_ipv6_frame_output_finalizer [C1.1.1:3] Not enough bytes to fragment 55616
I was under the impression that NWProtocolFramer is the way to fragment the frame for the specific use case but I'm confused at this 50k limit that we seem to be hitting.
Any ideas? Thanks!
I was under the impression that NWProtocolFramer is the way to fragment the frame for the specific use case but I'm confused at this 50k limit that we seem to be hitting.
I am assuming you meant dividing the data into smaller uniform UDP messages instead of fragmenting. If so, yes, using a NWProtocolFramer is the approach to divide your data into specific network frames so they can be written and read in the same way each time. This, in theory, gives your app the ability to reason about chunks of data more reliably. If you work with smaller frames do you receive this issue? Also, be mindful about how much data is being copied into deliverInputNoCopy.
Isn't "dividing the data into smaller uniform UDP messages" called... fragmentation? I may be missing some nomenclature here, are you referring to manually handled fragmentation vs fallback fragmentation that Eskimo talks about in this thread.
Seeing no issues with frames under around 50k, and given how much higher than maximumDatagramSize I'm guessing we are hitting another limit.
Looking around for documentation around deliverInputNoCopy I can't see any limits on the size of the underlying buffer, can you recommend a way of figuring out if I'm hitting the limit here?
Thank you!
Seeing no issues with frames under around 50k, and given how much higher than maximumDatagramSize I'm guessing we are hitting another limit. Looking around for documentation around deliverInputNoCopy I can't see any limits on the size of the underlying buffer, can you recommend a way of figuring out if I'm hitting the limit here?
My interpretation is that the size of the frames you are wanting to send is filling up the write buffer faster than space can become available to drain out this buffer. That is why lower the frame size works out. What is the use case here, is this audio data?
We are sending h264 compressed video frames, so it's quite normal to get 50kb+ frames going through
Still not having any luck with UDP, went back to the WWDC19 talk about implementing the framer and Tommy specifically talks about dliverInput saying:
So you can actually deliverInput of a message that's a megabyte long, a gigabyte long if you need to
I'm confused as to why I'm hitting this limitation of at just 50kb. Do you have any suggestions for a workaround?