Error during continuous transmission in QUIC DATAGRAM communication

Question

Created Oct ’24

Replies 3

Boosts 3

Participants 2

Hello, I have a question about sending data in QUIC DATAGRAM. Regarding sending data in QUIC DATAGRAM, when I create a NWConnectionGroup and then use the send method of that group to send data in sequence, quite often I get an Optional(POSIXErrorCode(rawValue: 89): Operation canceled) error.

A little Thread.sleep between sends improves the situation somewhat, but the above error still occurs. Also, since I want to send the frame data of the video in this communication process, adding a wait will drastically reduce performance and make the speed impractical. However, if send is executed continuously without adding weights, the above error will occur 80% of the time or more.

Is it necessary to send while monitoring some status when sending?

In communication using QUIC Stream, when connecting to the server with NWConnection and sending with its send method, the above error does not occur even if send is executed without wait, and data can be transferred with good performance.

I am trying to use DATAGRAM communication to further increase throughput, but I am not having much success, and there is not much information on DATAGRAM communication.

Thank you in advance for your help.

Answered by DTS Engineer in 810615022

I discussed this with the Network framework team and have some info for you. Let’s start here:

I am trying to use DATAGRAM communication to further increase throughput

We don’t expect datagrams to improve throughput. Which creates a decision point for you.

You could abandon this path entirely, in which case the ECANCELED is likely to be irrelevant to you.
OTOH, if you stick with datarams, we’re not entirely sure what’s triggering this ECANCELED error, so the best path forward would be to file a bug with the details. If you can attach a small test project that reproduces the issue, that’d be great. But don’t skimp on the sysdiagnose log. That’s important to make sure you bug gets routed correctly.

Please post your bug number, just for the record

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’24

Accepted Answer

I discussed this with the Network framework team and have some info for you. Let’s start here:

I am trying to use DATAGRAM communication to further increase throughput

We don’t expect datagrams to improve throughput. Which creates a decision point for you.

You could abandon this path entirely, in which case the ECANCELED is likely to be irrelevant to you.
OTOH, if you stick with datarams, we’re not entirely sure what’s triggering this ECANCELED error, so the best path forward would be to file a bug with the details. If you can attach a small test project that reproduces the issue, that’d be great. But don’t skimp on the sysdiagnose log. That’s important to make sure you bug gets routed correctly.

Please post your bug number, just for the record

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

MMAEDA OP

Oct ’24

Thank you for your response.

The program we have created is currently working as expected with QUIC Stream for the most part. Originally, we wanted to see how it would behave when communicating with DATAGRAM, but before we could see that, we first got an error sending the message, which is why we posted this topic.

On another platform (Ubuntu Linux), when client/server programs using msquic and C Language communicate with each other, sending without wait may slow down the process but does not cause an error, However, in the communication between the iOS app created this time and the server using msquic above, many errors occurred shortly after the start of transmission.

After that, when the send method of NWConnectionGroup was made to be executed serially using NSLock, the errors stopped occurring, but the CPU load became extremely high. (50-60% without NSLock, 100-130% with NSLock)

The situation has changed a bit, but as you said, I will find time to create a simple project and send it to you as a report.

Thank you very much.

0

Answer 3

DTS Engineer OP

Apple

Oct ’24

when the send method of NWConnectionGroup was made to be executed serially using NSLock, the errors stopped occurring

Oh, that’s interesting. In general, Network framework structures are meant to be thread safe, so the fact that serialisation helps with this suggests that there’s a bug with the type’s internal locking.

I will find time to create a simple project and send it to you as a report.

Thanks. That’s be most helpful.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0