> On 9. Jun 2017, at 12:16, Tommy Pauly <tpa...@apple.com> wrote: > > HI Michael, > >> On Jun 8, 2017, at 7:13 PM, Michael Tuexen >> <michael.tue...@lurchi.franken.de> wrote: >> >> On 8. Jun 2017, at 15:50, Tommy Pauly <tpa...@apple.com> wrote: >>> >>> Hello, >>> >>> I wanted to point the TAPS group to some of the work that we announced this >>> week at WWDC that relates to the Post-Sockets API effort. You can see a >>> video of the session here (relevant section at ~13:50), along with the >>> slides: >>> >>> https://developer.apple.com/videos/play/wwdc2017/707 >>> >>> In the current betas of iOS 11, we have introduced “User-Space Networking” >>> beneath our networking APIs. The transport and IP protocols are now being >>> co-located with the security and application protocols in the process, >>> meaning that we are no longer using sockets within the implementation of >>> these APIs. This shift allows us to reduce the context switches between >>> protocol layers, and could potentially open opportunities for the kind of >>> stack flexibility and customization that the TAPS group is looking at. >>> We’re excited to be making some first steps into a truly “Post-Sockets” >>> world! >> Hi Tommy, >> >> so this means I can run my own TCP stack and my own IPv6 stack in my >> application, if I understood that correctly. >> How is the port number space managed between the different applications? I'm >> wondering how the demultiplexing is >> done? >> Can I also use the API for a transport protocol supporting the port number >> concept, but not being UDP or TCP, >> like SCTP or UDP-Lite or DCCP or whatever might come up in the future? > > The ability to run your own stack is not currently exposed; the user-space > stack for TCP, etc, is part of the system library. However, this architecture > does open up the possibility to extend or modify this in the future. If > people have specific ways that they think this would be most useful to extend > and modify, please let me know. > > The kernel is still responsible for managing the port namespace between > applications, and demultiplexing incoming packets to the correct processes. > Since that is part of the kernel, the port demultiplexing still needs to > understand where to look for port numbers in known protocols. It seems like > for the use-case you’re mentioning for new protocols, it could be useful to > allow that logic to be extended, or ‘learn’ new protocols. This isn’t > something we’re doing now, but definitely an interesting idea! Leaving the port multiplexing / demultiplexing at the kernel makes a lot of sense. Are you doing something like: * open a TCP socket. * bind it. * set a socket option that you want to send/recv raw TCP packets That way you could pass the packets up and down to a userland stack and could coexist with a kernel stack. (Assuming that the kernel/userland boundary still uses sockets). However, that doesn't fit the figure shown a WWDC, where you had the IP stack and the TCP as part of the userland stack. So does the application the route selection, interface selection?
Is there any documentation available for the interface between kernel land and userland? Is the same architecture available on Mac OS X? Best regards Michael > > Thanks, > Tommy > >> >> Best regards >> Michael >>> >>> Thanks, >>> Tommy >>> _______________________________________________ >>> Taps mailing list >>> Taps@ietf.org >>> https://www.ietf.org/mailman/listinfo/taps >> >> _______________________________________________ >> Taps mailing list >> Taps@ietf.org >> https://www.ietf.org/mailman/listinfo/taps > _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
