Create network connections to send and receive data using the QUIC protocol.

Posts under QUIC tag

65 Posts

Post

Replies

Boosts

Views

Activity

Uploading over http gives "No buffer space available" errors
Hi, I'm uploading with a NSURLSessionUploadTask using a stream body and getting many "No buffer space available" errors. I'm uploading files to a google drive bucket with a PUT from a catalyst app on osx. It looks like the connection might be using quic, and I'm doing parallel uploads to the same host. Does an http connection that choses to use quic expose me to a bunch of unexpected UDP errors? Might it be a bug causing the stream body to not be buffered correctly, as a file would. Might it be being all read at once? Or might something else on my system be interfering with the available socket memory? When it does work it's really very fast but it keeps falling over. Any suggestions as to how best avoid/fix this? Thanks, Paul
11
0
3.6k
Nov ’22
QUIC datagram draft support?
QUIC support in Network framework in iOS 15 and macOS 12 seems to be aware of the datagram draft, but there doesn’t seem to be any way to configure NWProtocolQUIC.Options to set the datagram transport parameter (0x20). If I configure the server to send a datagram to a Swift client, it closes the connection with a PROTOCOL_VIOLATION frame with the error message "DATAGRAM frame size too big". Given that Eric Kinnear at Apple is an author of the datagram draft, is support for this intentionally missing? https://www.ietf.org/archive/id/draft-ietf-quic-datagram-03.html You can see a minimal example here: https://github.com/alta/swift-quic-datagram-example Thanks!
5
0
2.7k
Jun ’22
HTTP/3 in your App
This content has now moved to TN3102: https://developer.apple.com/documentation/dts-technotes/tn3102-http3-in-your-app HTTP/3 is a major new feature in iOS 15. While you wait for your server to add support for it, here’s how you can test it today in your app: Install iOS 15.0 beta on a test device (HTTP/3 is not supported in the simulator). In Settings > Developer, under the Networking group, enable HTTP/3. Using Xcode 13.0 beta, create a new project from the iOS > App template. Set the Interface popup to Storyboard and the Language popup to Swift. Change ViewController.swift to the code shown below. In Main.storyboard add a Test button and wire it up to testAction(_:). Run the app on your device. Tap your Test button. Your app will print something similar to: task will start, url: <# Your H3 URL Here #> protocols: ["h3-29"] task finished with status 200, bytes 703 The protocols array shows the protocol used for each HTTP transaction. In this case there was a single HTTP/3 transaction. In some cases you may see the protocol being returned as (h2) or even (http1.1). If this is the case then run the transaction again, as URLSession may need to apply the H3 service discovery option that your server sent back on the previous HTTP response. Service discovery for HTTP/3 is performed in one of the following ways: the recommended approach is to configure your DNS server to advertise the HTTPS resource record for alpn="h3,h2". You should also configure your server to respond back with the Alt-Svc header that advertises HTTP/3. For example, Alt-Srv: h3=":443"; ma=2592000. To attempt to use HTTP/3 on the first transaction, try using the assumesHTTP3Capable property on the URLRequest being used to execute the dataTask in URLSession. For cases where HTTP/3 is not supported on the server, or over the network, you will see the protocol fall back to (h2) or (http1.1). For more information on this, please see the WWDC session for Accelerate networking with HTTP/3 and QUIC. NOTE: Servers that support HTTP3 should be based on Draft 29 or later. If you experience issues while debugging your network transactions, take a look at these requests in the Network Instruments tool to debug what you are seeing being sent back from your server. For more on this, see the WWDC session for Analyze HTTP traffic in Instruments. import UIKit class ViewController: UIViewController, URLSessionDataDelegate { private var session: URLSession! @IBAction private func testAction(_ sender: Any) { if self.session == nil { let config = URLSessionConfiguration.default config.requestCachePolicy = .reloadIgnoringLocalCacheData self.session = URLSession(configuration: config, delegate: self, delegateQueue: .main) } let urlStr = "<# Your H3 URL Here #>" let url = URL(string: urlStr)! var request = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalCacheData, timeoutInterval: 60.0) request.assumesHTTP3Capable = true print("task will start, url: \(url.absoluteString)") self.session.dataTask(with: request) { (data, response, error) in if let error = error as NSError? { print("task transport error \(error.domain) / \(error.code)") return } let response = response as! HTTPURLResponse let data = data! print("task finished with status \(response.statusCode), bytes \(data.count)") }.resume() } func urlSession(_ session: URLSession, task: URLSessionTask, didFinishCollecting metrics: URLSessionTaskMetrics) { let protocols = metrics.transactionMetrics.map { $0.networkProtocolName ?? "-" } print("protocols:", protocols) } } Matt Eaton DTS Engineering, CoreOS meaton3@apple.com Change history: 16th June 2021 - Initial Post.
0
0
4.1k
Feb ’22
iOS App Crash on com.apple.network.connections
Dear Team, We are getting new Crashes in our Firebase recently for iOS 15+ OS Devices. But we are not able to get any meaningful message from Crashlytics. Also when we are testing, we are not able to reproduce the issue as well. Crash 1 - Crashed: com.apple.network.connections EXC_BREAKPOINT 0x00000001f1b3e980 Crashed: com.apple.network.connections 0 libquic.dylib 0x69980 qlog_abort_internal + 272 1 libquic.dylib 0x6996c qlog_abort_internal + 252 2 libquic.dylib 0x63a2c quic_frame_write_PADDING + 640 3 libquic.dylib 0x9c6ec _quic_packet_builder_assemble + 2048 4 libquic.dylib 0x2508 quic_packet_builder_assemble + 124 5 libquic.dylib 0x36704 quic_assemble_and_encrypt + 260 6 libquic.dylib 0x37a4c __quic_send_frames_for_key_state_block_invoke.106 + 1016 7 libnetwork.dylib 0x60e374 nw_protocol_data_access_buffer + 1160 8 libquic.dylib 0x1c910 __quic_send_frames_for_key_state_block_invoke + 200 9 libnetwork.dylib 0xbc34 nw_protocol_service_requested_outbound_data + 360 10 libnetwork.dylib 0x5f4a68 nw_protocol_request_outbound_data + 128 11 libquic.dylib 0x22d00 quic_send_frames_for_key_state + 1376 12 libquic.dylib 0x18f90 _quic_send_frames_with_override + 316 13 libquic.dylib 0x56758 quic_frame_process_PATH_CHALLENGE + 36 14 libquic.dylib 0x63c98 quic_frame_process + 140 15 libquic.dylib 0x16648 quic_process_inbound + 1360 16 libnetwork.dylib 0x60e374 nw_protocol_data_access_buffer + 1160 17 libquic.dylib 0x15454 __quic_handle_inbound_block_invoke + 152 18 libquic.dylib 0x1210 quic_handle_inbound + 124 19 libnetwork.dylib 0x5ee984 __nw_protocol_implementation_get_input_internal_block_invoke + 136 20 libnetwork.dylib 0x5ed99c nw_protocol_implementation_get_input_internal + 252 21 libnetwork.dylib 0x5eca28 nw_protocol_implementation_read + 392 22 libnetwork.dylib 0x5ec0ac nw_protocol_implementation_input_available + 96 23 libnetwork.dylib 0x539904 nw_channel_add_input_frames + 9404 24 libnetwork.dylib 0x537358 nw_channel_update_input_source + 324 25 libnetwork.dylib 0x536570 __nw_channel_create_block_invoke.29 + 72 26 libdispatch.dylib 0x3950 _dispatch_client_callout + 20 27 libdispatch.dylib 0x6e04 _dispatch_continuation_pop + 504 28 libdispatch.dylib 0x19d60 _dispatch_source_invoke + 1356 29 libdispatch.dylib 0xcf20 _dispatch_workloop_invoke + 1784 30 libdispatch.dylib 0x16318 _dispatch_workloop_worker_thread + 656 31 libsystem_pthread.dylib 0x11b0 _pthread_wqthread + 288 32 libsystem_pthread.dylib 0xf50 start_wqthread + 8
1
0
2.1k
Nov ’21
Uploading over http gives "No buffer space available" errors
Hi, I'm uploading with a NSURLSessionUploadTask using a stream body and getting many "No buffer space available" errors. I'm uploading files to a google drive bucket with a PUT from a catalyst app on osx. It looks like the connection might be using quic, and I'm doing parallel uploads to the same host. Does an http connection that choses to use quic expose me to a bunch of unexpected UDP errors? Might it be a bug causing the stream body to not be buffered correctly, as a file would. Might it be being all read at once? Or might something else on my system be interfering with the available socket memory? When it does work it's really very fast but it keeps falling over. Any suggestions as to how best avoid/fix this? Thanks, Paul
Replies
11
Boosts
0
Views
3.6k
Activity
Nov ’22
Cant able to test HTTP/3 in iOS 16
I am trying to enable HTTP/3 support for network calls in my app, While i was testing i could see my protocol as h3 in iOS15 but in iOS 16 it always comes as h2 even though after enabling assumesHTTP3Capable. Also enabling HTTP/3 in iOS 16 has been replaced with L4S. My question is how to test HTTP/3 support in iOS 16?
Replies
3
Boosts
0
Views
3.5k
Activity
Nov ’22
QUIC datagram draft support?
QUIC support in Network framework in iOS 15 and macOS 12 seems to be aware of the datagram draft, but there doesn’t seem to be any way to configure NWProtocolQUIC.Options to set the datagram transport parameter (0x20). If I configure the server to send a datagram to a Swift client, it closes the connection with a PROTOCOL_VIOLATION frame with the error message "DATAGRAM frame size too big". Given that Eric Kinnear at Apple is an author of the datagram draft, is support for this intentionally missing? https://www.ietf.org/archive/id/draft-ietf-quic-datagram-03.html You can see a minimal example here: https://github.com/alta/swift-quic-datagram-example Thanks!
Replies
5
Boosts
0
Views
2.7k
Activity
Jun ’22
HTTP/3 in your App
This content has now moved to TN3102: https://developer.apple.com/documentation/dts-technotes/tn3102-http3-in-your-app HTTP/3 is a major new feature in iOS 15. While you wait for your server to add support for it, here’s how you can test it today in your app: Install iOS 15.0 beta on a test device (HTTP/3 is not supported in the simulator). In Settings > Developer, under the Networking group, enable HTTP/3. Using Xcode 13.0 beta, create a new project from the iOS > App template. Set the Interface popup to Storyboard and the Language popup to Swift. Change ViewController.swift to the code shown below. In Main.storyboard add a Test button and wire it up to testAction(_:). Run the app on your device. Tap your Test button. Your app will print something similar to: task will start, url: <# Your H3 URL Here #> protocols: ["h3-29"] task finished with status 200, bytes 703 The protocols array shows the protocol used for each HTTP transaction. In this case there was a single HTTP/3 transaction. In some cases you may see the protocol being returned as (h2) or even (http1.1). If this is the case then run the transaction again, as URLSession may need to apply the H3 service discovery option that your server sent back on the previous HTTP response. Service discovery for HTTP/3 is performed in one of the following ways: the recommended approach is to configure your DNS server to advertise the HTTPS resource record for alpn="h3,h2". You should also configure your server to respond back with the Alt-Svc header that advertises HTTP/3. For example, Alt-Srv: h3=":443"; ma=2592000. To attempt to use HTTP/3 on the first transaction, try using the assumesHTTP3Capable property on the URLRequest being used to execute the dataTask in URLSession. For cases where HTTP/3 is not supported on the server, or over the network, you will see the protocol fall back to (h2) or (http1.1). For more information on this, please see the WWDC session for Accelerate networking with HTTP/3 and QUIC. NOTE: Servers that support HTTP3 should be based on Draft 29 or later. If you experience issues while debugging your network transactions, take a look at these requests in the Network Instruments tool to debug what you are seeing being sent back from your server. For more on this, see the WWDC session for Analyze HTTP traffic in Instruments. import UIKit class ViewController: UIViewController, URLSessionDataDelegate { private var session: URLSession! @IBAction private func testAction(_ sender: Any) { if self.session == nil { let config = URLSessionConfiguration.default config.requestCachePolicy = .reloadIgnoringLocalCacheData self.session = URLSession(configuration: config, delegate: self, delegateQueue: .main) } let urlStr = "<# Your H3 URL Here #>" let url = URL(string: urlStr)! var request = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalCacheData, timeoutInterval: 60.0) request.assumesHTTP3Capable = true print("task will start, url: \(url.absoluteString)") self.session.dataTask(with: request) { (data, response, error) in if let error = error as NSError? { print("task transport error \(error.domain) / \(error.code)") return } let response = response as! HTTPURLResponse let data = data! print("task finished with status \(response.statusCode), bytes \(data.count)") }.resume() } func urlSession(_ session: URLSession, task: URLSessionTask, didFinishCollecting metrics: URLSessionTaskMetrics) { let protocols = metrics.transactionMetrics.map { $0.networkProtocolName ?? "-" } print("protocols:", protocols) } } Matt Eaton DTS Engineering, CoreOS meaton3@apple.com Change history: 16th June 2021 - Initial Post.
Replies
0
Boosts
0
Views
4.1k
Activity
Feb ’22
iOS App Crash on com.apple.network.connections
Dear Team, We are getting new Crashes in our Firebase recently for iOS 15+ OS Devices. But we are not able to get any meaningful message from Crashlytics. Also when we are testing, we are not able to reproduce the issue as well. Crash 1 - Crashed: com.apple.network.connections EXC_BREAKPOINT 0x00000001f1b3e980 Crashed: com.apple.network.connections 0 libquic.dylib 0x69980 qlog_abort_internal + 272 1 libquic.dylib 0x6996c qlog_abort_internal + 252 2 libquic.dylib 0x63a2c quic_frame_write_PADDING + 640 3 libquic.dylib 0x9c6ec _quic_packet_builder_assemble + 2048 4 libquic.dylib 0x2508 quic_packet_builder_assemble + 124 5 libquic.dylib 0x36704 quic_assemble_and_encrypt + 260 6 libquic.dylib 0x37a4c __quic_send_frames_for_key_state_block_invoke.106 + 1016 7 libnetwork.dylib 0x60e374 nw_protocol_data_access_buffer + 1160 8 libquic.dylib 0x1c910 __quic_send_frames_for_key_state_block_invoke + 200 9 libnetwork.dylib 0xbc34 nw_protocol_service_requested_outbound_data + 360 10 libnetwork.dylib 0x5f4a68 nw_protocol_request_outbound_data + 128 11 libquic.dylib 0x22d00 quic_send_frames_for_key_state + 1376 12 libquic.dylib 0x18f90 _quic_send_frames_with_override + 316 13 libquic.dylib 0x56758 quic_frame_process_PATH_CHALLENGE + 36 14 libquic.dylib 0x63c98 quic_frame_process + 140 15 libquic.dylib 0x16648 quic_process_inbound + 1360 16 libnetwork.dylib 0x60e374 nw_protocol_data_access_buffer + 1160 17 libquic.dylib 0x15454 __quic_handle_inbound_block_invoke + 152 18 libquic.dylib 0x1210 quic_handle_inbound + 124 19 libnetwork.dylib 0x5ee984 __nw_protocol_implementation_get_input_internal_block_invoke + 136 20 libnetwork.dylib 0x5ed99c nw_protocol_implementation_get_input_internal + 252 21 libnetwork.dylib 0x5eca28 nw_protocol_implementation_read + 392 22 libnetwork.dylib 0x5ec0ac nw_protocol_implementation_input_available + 96 23 libnetwork.dylib 0x539904 nw_channel_add_input_frames + 9404 24 libnetwork.dylib 0x537358 nw_channel_update_input_source + 324 25 libnetwork.dylib 0x536570 __nw_channel_create_block_invoke.29 + 72 26 libdispatch.dylib 0x3950 _dispatch_client_callout + 20 27 libdispatch.dylib 0x6e04 _dispatch_continuation_pop + 504 28 libdispatch.dylib 0x19d60 _dispatch_source_invoke + 1356 29 libdispatch.dylib 0xcf20 _dispatch_workloop_invoke + 1784 30 libdispatch.dylib 0x16318 _dispatch_workloop_worker_thread + 656 31 libsystem_pthread.dylib 0x11b0 _pthread_wqthread + 288 32 libsystem_pthread.dylib 0xf50 start_wqthread + 8
Replies
1
Boosts
0
Views
2.1k
Activity
Nov ’21