I understand that GCD and it's underlying implementations have evolved over time. And many things have not been shared explicitly in Apple documentation. The most concepts of DispatchQueue (serial and concurrent queues), DispatchQoS, target queue and system provided queues: main and globals etc. I have some doubts & questions to clarify: [Main Dispatch Queue] [Link] Because the main queue doesn't behave entirely like a regular serial queue, it may have unwanted side-effects when used in processes that are not UI apps (daemons). For such processes, the main queue should be avoided. What does it mean? Can you elaborate? [Global Concurrent Dispatch Queues] Are they global to a process or across processes on a device. I believe it is the first case but just wanted to be sure. [Global Concurrent Dispatch Queues] Does system create 4 (for each QoS) * 2 (over-commiting and non-overcommiting queues) = 8 queues in all. When does which type of queue comes into play? [Custom Queue][Target Queue concept] [swift-corelibs-libdispatch/man/dispatch_queue_create.3] QUOTE The default target queue of all dispatch objects created by the application is the default priority global concurrent queue. UNQUOTE Is this stil true? We could not find a mention of this in any latest official apple documentation (though some old forum threads (one more) and github code documentation indicate the same). The official documentation only says: [dispatch_set_target_queue] QUOTE If you want the system to provide a queue that is appropriate for the current object UNQUOTE [dispatch_queue_create_with_target] QUOTE Specify DISPATCH_TARGET_QUEUE_DEFAULT to set the target queue to the default type for the current dispatch queue.UNQUOTE [Dispatch>DispatchQueue>init] QUOTE Specify DISPATCH_TARGET_QUEUE_DEFAULT if you want the system to provide a queue that is appropriate for the current object. UNQUOTE What is the difference between passing target queue as 'nil' vs 'DISPATCH_TARGET_QUEUE_DEFAULT' to DispatchQueue init? [Custom Queue][Target Queue concept] [dispatch_set_target_queue] QUOTE The system doesn't allocate threads to the dispatch queue if it has a target queue, unless that target queue is a global concurrent queue. UNQUOTE The system does allocate threads to the custom dispatch queues that have global concurrent queue as the default target. What does that mean? Why does targetting to global concurrent queues mean in that case? [System / GCD Thread Pool] that excutes work items from DispatchQueue: Is this thread pool per queue? or across queues per process? or across processes per device?

One: does it involve below or any other steps? Create a socket (AF_INET6, SOCK_DGRAM, IPPROTO_UDP) Bind it to AF_INET6, in6addr_any, port X. Disable IPV6_V6ONLY using setsockopt. Second: If answer to above is yes, in other operating system, if a datagram would have got received over IPv4, it would have lead to IPv4-mapped IPv6 address in the recvfrom call and protocol would have been considered udp6. Third: is UDP46 only supported by Apple Kernel (is it not a POSIX standard behaviour) and also within Apple Kernel - not supported on all versions? Why this question? We created a NWListener on a local port, using udp and when we ran a 'netstat -an -p udp', it showed protocol as 'udp46'

We have an application design where, every instance (process) is acting as a UDP server as well as UDP client, using the same UDP port: to listen & respond (as a server) to multiple destinations as well to send (as a client) to multiple destinations. This considering the implicit nature of UDP being connectionless. At any given point in time, I would be, as a server, talking to many clients and as a client, talking to many servers. We were using BSD sockets for the purpose across all our target platforms including Apple Kernel (macOS, iOS, iPadOS, tvOS, watchOS etc.). Then we learnt about limitation on watchOS, where we started exploring 'Network Framework' as an alternative to BSD sockets on watchOS (or even others on Apple Kernel). This is to understand, how can we achieve the same (if at all) using 'Network Framework'? Process A [To act as UDP server] We will have NWListener on inaddrany, local port X, using UDP Does it implicitly work for both IPv4 and IPv6 incoming data? In case of BSD sockets, we would have created two sockets - one bound on INADDR_ANY and other on in6addr_any. Does in case of NWListener, also internally it creates two sockets - one for IPv4 and other for IPv6? For every incoming data from a client (which may not be on Apple Kernel and hence not using NWConnection), a NWConnection would be created on this UDP server (off course, if NWConnection does not already exist for the same local and remote IP/Port). Just for our clarity: An underlying socket is not created (like it would have in case of TCP)? The underlying data exchange between the UDP clients and this UDP server would happen on the same socket bound on port X? NWConnection for UDP is more a logical construct created to represent a “UDP flow”, that is, a sequence of datagrams, including both inbound and outbound, that share the same local IP / port and same remote IP / port tuple, where for 'local IP/Port', there would a socket bound on it internally. I can use the same NWConnection to respond (send data) back to the client. Since UDP is connectionless, how do we manage the lifecycle of these NWConnection(s) getting created? Though there is no socket resource to be freed per NWConnection basis BUT there must be some other system resources like memory being occupied. We understand that once cancelled, if we receive a datagram from the same client (actually, on the same UDP flow), the listener will create a new connection. [To act as UDP client] We will have to create a NWConnection to a UDP server We would like to have that NWConnection internally use the same local port X to send data to the remote UDP server, is that possible? The interface to init NWConnection seem to only take remote endpoint as an input and protocol as an input. And this we would like to do for all UDP servers we want to connect as client? Which would mean multiple NWConnection - one for each UDP Server we want to communicate to BUT same local port X is being used on the UDP Client. I will receive the response from the Server also on the same NWConnection (if still active and not cancelled). The client cancels the NWConnection when no more intends to talk to the same UDP Server.