{"id":1995,"date":"2017-12-19T12:36:30","date_gmt":"2017-12-19T20:36:30","guid":{"rendered":"http:\/\/blogs.msdn.microsoft.com\/commandline\/?p=1995"},"modified":"2019-02-18T13:28:45","modified_gmt":"2019-02-18T21:28:45","slug":"af_unix-comes-to-windows","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/commandline\/af_unix-comes-to-windows\/","title":{"rendered":"AF_UNIX comes to Windows"},"content":{"rendered":"

Introduction:<\/span>\u00a0<\/span><\/h2>\n

Beginning in Insider Build <\/a><\/span>17063<\/span>, you\u2019ll be able to use the <\/span>unix<\/span> socket (<\/span>AF_UNIX<\/span>)<\/span> address family on Windows<\/span> to communicate between <\/span>W<\/span>in32 processes<\/span>. <\/span>Unix<\/span><\/a> sockets allow inter-process communication<\/span> (IPC)<\/span> between process<\/span>es<\/span> on the same machine.<\/span>\u00a0<\/span><\/p>\n

Overview<\/span>:<\/span>\u00a0<\/span><\/h2>\n

Support for the <\/span>unix<\/span> socket<\/span> has existed both in BSD and Linux for the longest time, but, not on Windows.<\/span> On Windows, there were some alternatives for local IPC, such as <\/span>named pipes<\/span><\/a>.<\/span> But, calling conventions are different between the named pipes and sockets<\/span>, making writing low-maintenance cross-platform applications difficult. <\/span>For<\/span> example, <\/span>one such place <\/span>where these two constructs differ (other than the API) is terminating the connection. BSD Socket API provides a bidirectional close semantics using <\/span><a href=\"http:\/\/man7.org\/linux\/man-pages\/man2\/shutdown.2.html\"><span>shutdown<\/span><\/a><span><\/code>. There is no direct equivalent of that in named pipes.<\/span> Such differences <\/span>make it difficult to<\/span> port<\/span> unix<\/span> socket <\/span>applications<\/span> from Linux to Windows <\/span>and vice versa;<\/span> up until now!<\/span>\u00a0<\/span><\/p>\n

Build <\/span>17063<\/span> brings native support for the <\/span>unix<\/span> socket <\/span>to Windows. Starting this build, two Win<\/span>32<\/span> process<\/span>es<\/span> can use the AF_UNIX address family over <\/span>Winsock API<\/span><\/a> (which is very similar to the BSD socket API) to communicate with each other.<\/span> Currently, the support only exists for the <\/span>stream (<\/span>SOCK_STREAM<\/span>)<\/span> socket type<\/span>, which is a connection-oriented protocol for one-to-one communication. Support for the datagram (SOCK_DGRAM) can be considered in future depending on the <\/span>adoption, feedback and scenario<\/span>s<\/span>.<\/span>\u00a0<\/span><\/p>\n

Addressing scheme – <\/span>sockaddr_un<\/span>:<\/span>\u00a0<\/span><\/h2>\n

The \u2018<\/span>sockaddr_un<\/span>\u2019 structure is used for defining the <\/span>address of a <\/span>unix<\/span> socket.<\/span> In the Windows implementation of the <\/span>unix<\/span> socket, we have kept the name, definition and semantics of the <\/span>unix<\/span> socket address the same as that in Linux<\/span>, to make cross-platform development easier<\/span>.<\/span>\u00a0<\/span><\/p>\n

There are three different addressing <\/span>formats<\/span> for <\/span>unix<\/span> sockets. <\/span>\u2018pathname\u2019, \u2018abstract\u2019 and \u2018unnamed\u2019 sockets. <\/span>\u2018pathname\u2019 sockets are bound to the filesystem<\/span>, where<\/span> in <\/span>the \u2018<\/span>sun_path<\/span>\u2019 member of the struct is used to specify a null-terminated UTF-8 file system path. You can expect the same from the Windows implementation<\/span>,<\/span> where \u2018<\/span>sun_path<\/span>\u2019 specifies a Win32 UTF-8 file system path.<\/span>\u00a0<\/span><\/p>\n

The second category is the \u2018abstract\u2019 socket address where the <\/span>first character in \u2018<\/span>sun_path<\/span>\u2019 is a <\/span>null<\/span><\/i> byte.<\/span> Windows implementation of AF_UNIX socket can also accept abstract addresses. The one difference noteworthy here is that the Windows <\/span>unix<\/span> socket <\/span>implementation <\/span>currently does not support <\/span>the <\/span>auto<\/span>bind<\/span> feature whereby an abstract address is auto-generated by the implementation on behalf of the user.<\/span>\u00a0<\/span><\/p>\n

Lastly, \u2018unnamed\u2019 sockets, where the socket is bound to a pathname with no name.<\/span> This is also supported on Windows <\/span>unix<\/span> socket implementation<\/span>. Although, one of the socket API\u2019s <\/span>socketpair<\/span><\/a> that generates unnamed sockets, itself is not supported in Winsock<\/span> 2.0<\/span>.<\/span>\u00a0<\/span><\/p>\n

Security:<\/span>\u00a0<\/span><\/h2>\n

Unix sockets provide a mechanism for secure communication.<\/span> C<\/span>ommunication <\/span>over <\/span>unix<\/span> sockets<\/span> can be secured by controlling the file<\/span> (or directory)<\/span> permissions on the pathname sockets<\/span> (<\/span>or the parent directory<\/span>)<\/span>. <\/span>For example, <\/span>the <\/span>bind<\/span><\/i> socket API creates a \u2018socket\u2019 file with the given pathname<\/span>. <\/span>The creation of the new socket file will fail if the calling process does not has write permission on the directory where the file is being created. <\/span>Similarly, for connecting to a stream socket, the connecting process should have write permission on the socket. <\/span>The same level of security is available and enforced on <\/span>the <\/span>Windows <\/span>unix<\/span> socket<\/span> implementation<\/span>. <\/span>See the man page on AF_UNIX for more details<\/span> on the security<\/span>.<\/span>\u00a0<\/span><\/p>\n

Implementation:<\/span>\u00a0<\/span><\/h2>\n

Majority of the functionality for the Windows AF_UNIX is implemented in the Windows kernel in a driver<\/span>:<\/span> afunix.sys<\/span><\/i>. <\/span>The <\/span>Windows kernel <\/span>networking <\/span>stack provides a very pluggable and extensible model, that makes it easy to support new network providers.<\/span> The socket file itself <\/span>that is created as part of the bind call <\/span>is a custom <\/span>NTFS reparse point<\/span><\/a>.<\/span>\u00a0<\/span><\/p>\n

Unsupported<\/span>\\unavailable<\/span>:<\/span>\u00a0<\/span><\/h2>\n

Summarizing from the above, the following Linux <\/span>unix<\/span> socket<\/span> features are either <\/span>currently<\/span><\/b> unavailable or unsupported in the Windows <\/span>unix<\/span> socket<\/span> implementation.<\/span>\u00a0<\/span><\/p>\n