Networking Feedback Feb 2018

This thread has been locked by a moderator.

IMPORTANT The deadline for feedback has now expired.

I’d like to thank everyone who responded. I won’t be posting the results publicly, but rest assured that your feedback will be appreciated by the networking teams here at Apple.

If you missed the deadline you have a couple of options:

  • If your feedback is about some specific piece of functionality you’d like to see added to the system, please file an enhancement request with the details.

  • If your feedback is more general, you should open a thread in the Core OS > Networking topic area and we can discuss things there.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

ps The following is a copy of the original post, just for the record.

I’m soliciting feedback about the networking APIs on Apple’s various platforms. The focus here is on commonly-used user-space networking APIs; think

NSURLSession
,
NSStream
and BSD Sockets, not VPN, NKEs, Wi-Fi management, and so on.

If you’d like to take part, please note:

  • I’m collecting responses via email.

  • Send your response to me directly; my email address is in my signature, below.

  • Use the subject line “Networking Feedback Feb 2018”.

  • Below you’ll find a specific set of questions. Feel free to answer as many or as few as you like, or as are appropriate to your product.

  • Or just ignore the questions completely and send me general feedback.

  • Feedback is due before 11pm (Pacific), Sun, 11 Mar 2018.

  • I will reply to every submission with a simple ack.

  • In specific circumstances I may write back with follow-up questions.

IMPORTANT I will collate the results and distribute them internally at Apple. If you’d like me to withhold your name or affiliation, please let me know. Your feedback will not be distributed outside of Apple.

[… signature elided …]

Q1 If your product is still using the deprecated

NSURLConnection
or
NSURLDownload
APIs, is that because:
  • You just haven’t got around to adopting

    NSURLSession
    (A)
  • NSURLSession
    is missing some feature that you need (B)
  • Other (C)

For B and C, please provide some details.

Q2 If your product is still using the deprecated

CFHTTPStream
API, is that because:
  • You just haven’t got around to adopting

    NSURLSession
    (A)
  • NSURLSession
    is missing some feature that you need (B)
  • Other (C)

For B and C, please provide some details.

Q3 If your product is still using the FTP protocol, is that because:

  • It’s a legacy feature you haven’t got around to removing (A)

  • Your product interacts with hardware that only supports FTP (B)

  • FTP is an absolute requirement of the folks who pay the bills (C)

  • Other (D)

For B, C and D, please provide some details.

Q4 If your product is still using the FTP protocol, do you use:

  • NSURLSession
    (A)
  • NSURLConnection
    /
    NSURLDownload
    (B)
  • CFFTPStream
    directly (C)
  • A third-party library that uses

    CFFTPStream
    (D)
  • A third-party library with its own core FTP code (E)

  • Other (F)

For D, E or F, please provide some details.

Q5 If your product uses a third-party library layered on top of

NSURLSession
, did you choose that library because:
  • It provides specific functionality you need (A)

  • It has a nicer programming interface (B)

  • Other (C)

In all cases, please let us know which library you’re using. In case C, please provide some details.

Q6 If your product uses a third-party HTTP[S] library that is not layered on top of

NSURLSession
(one that uses its own core HTTP code) is that because:
  • It helps with cross-platform compatibility (A)

  • It’s intrinsic to your development environment (B)

  • NSURLSession
    is missing some feature that you need (C)
  • The third-party library performs better than

    NSURLSession
    (D)
  • The third-party library is more reliable than

    NSURLSession
    (E)
  • Other (F)

For C, D, E and F, please provide some details.

Q7 If your product uses the HTTP[S] protocol but does not use HTTP/2, is that because:

  • You use HTTP, not HTTPS (A)

  • Your product talks to a variety of HTTP servers, some of which support HTTP/2 and some of which don’t (B)

  • Your product talks to a specific HTTPS server that’s outside of your control (C)

  • Your product talks to a specific HTTPS server that you control but you haven’t yet updated to use HTTP/2 (D)

  • Other (E)

For E, please provide some details.

Q8 For

NSURLSession
[*], what are the enhancement requests or bugs that you’d most like to see addressed? Please list up to five in order from most to least desired. Ideally we’d like a list of bug numbers, with all the details in the corresponding bug report.

[*] This includes the core

NSURLSession
API and all its related technologies, including:
  • Async API structure (delegates, blocked-based convenience APIs, and so on)
  • Swift integration
  • Requests and responses
  • Caching
  • Cookies
  • Authentication (including credentials and their storage)
  • Background sessions
  • Core HTTP and HTTP/2 protocol implementations
  • Debugging tools
  • Security (HTTPS)
  • Performance
  • Task metrics
  • Task prioritisation
  • Stream tasks

Q9 If your app uses the reachability API (

SCNetworkReachability
, either directly or via a wrapper like the [Reachability][SampleReach] sample code), is that because:
  • Someone said you needed reachability and you’re not entirely sure why (A)

  • You just haven’t got around to adopting the new

    waitsForConnectivity
    support in
    NSURLSession
    (B)
  • You want to preflight network requests, that is, you don’t make a request until reachability indicates that it might work (C)

  • You want to know when it’s a good time to retry a failed request (D)

  • You’re using

    SCNetworkReachabilityCreateWithAddressPair
    to monitor the state of a specific connection (E)
  • You want to know what type of networking is available, for example, WWAN or Wi-Fi (F)

  • You’re using it solely to update your app’s user interface (G)

  • Other (H)

For C, we’d really like some details on why you’re preflighting network requests.

For F, G and H, please provide some general details.

[SampleReach]: http://developer.apple.com/library/ios/#samplecode/Reachability/

Q10 If your product works directly on top of the TCP protocol, what API do you use:

  • BSD Sockets (A)

  • CFSocket
    (B)
  • NSStream
    (C)
  • NSURLSessionTask
    (D)
  • NWTCPConnection
    (E)
  • A third-party library (F)

  • Other (G)

For F, please let us know which library you’re using. For G, please provide some details.

Q11 If you answered the previous question, please provide information about your TLS (aka SSL) use:

  • You don’t need TLS (A)

  • You use the TLS implementation provided by the API you’re using (for example, in

    NSURLSessionTask
    you can enable TLS by calling
    -startSecureConnection
    ) (B)
  • You use Secure Transport to implement TLS (C)

  • You use OpenSSL to implement TLS (D)

  • You use some other third-party TLS library (E)

For D, please explain why you use OpenSSL. For E, please provide some details.

Q12 If your product uses BSD Sockets for networking, is that because:

  • It helps with cross-platform compatibility (A)

  • You have existing code that you don’t want to rewrite (B)

  • You’re using UDP, not TCP (C)

  • You’re using one of the more obscure features of BSD Sockets (raw IP, routing sockets, and so on) for which there is no equivalent higher-level API (D)

  • The equivalent higher-level API would otherwise be appropriate but is missing some small feature that you need (E)

  • Your code performs better than the equivalent high-level API (F)

  • Your code is more reliable than the equivalent high-level API (G)

  • Other (H)

For D through H, please provide some details.

Q13 Are you interested in adopting the QUIC protocol?

Q14 Are there any other existing or future networking protocols that would be useful to your product? Remember that the focus here is on commonly-used user-space networking APIs, so please restrict yourself to protocols that make sense in that context.

Q15 When debugging problems with the networking features of your product, which tools do you typically use?

  • Wireshark (A)

  • Some other packet trace tool (B)

  • A debugging HTTP proxy (C)

  • CFNetwork diagnostic logging (D)

  • sysdiagnose logs (E)

  • Other (F)

For B, C and F, please provide details.

Q16 In the context of debugging problems with the networking features of your product, is there a specific tool that you’d like Apple to provide?

Up vote post of eskimo
11k views