3 ms·

socketing stuff will help abstract it, but Unix sockets are simply better out of the box Can you elaborate? Do you mean performance? Because the on the C level

by stinos 6y ago

socketing stuff will help abstract it, but Unix sockets are simply better out of the box Can you elaborate? Do you mean performance? Because the on the C level both use (apart from some minor differences, which aren't enough to call one 'simply better' than the other) the same berkeley socket API.

tombert 6y ago
Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP. I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.
- int_19h 6y ago
  Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection. The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).

by stinos 6y ago

tombert 6y ago

Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP. I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.

int_19h 6y ago
Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection. The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).