4 ms·

This sounds like a half-closed socket. I helped with WinRT socket API for Windows; we had to decide whether to support that or not. In the end, we couldn't co

This sounds like a half-closed socket. I helped with WinRT socket API for Windows; we had to decide whether to support that or not. In the end, we couldn't come up with a truly legitimate case where an app really needs to do this. Even with no realistic use cases and no efficiency gains, we still got complaints from a small number of developers who wanted the flexibility of closing a socket one way but not the other.

wahern 10y ago
Huh? No realistic use cases? A half-closed socket is how you emulate EOF. It's like saying that EOF has no realistic use case; that _every_ protocol should implement a custom channeling and signaling mechanism at the application layer in order to get bidirectional streams, even though they're using TCP sockets. Now, many of the most popular protocols do that, but they do that because they're intended to be universally deployed and must deal with all the random pathological cases out in the wild. But if you don't have to worry about broken software, such as when you know there won't be broken proxies or routers in your path, then you can dramatically simplify many purpose-built protocols. As a practical matter most people can safely make that assumption. Most of the time it's cheaper and easier (in the grand scheme of things) to make the broken software shoulder the burden. Not everybody is writing software for Cloudflare or Chrome; and fortunately _most_ responsible vendors do a decent job at implementing standards correctly. I hope there's some confusion on your part or my part, and that you just didn't admit that WinRT was completely broken by design. That should be a hanging offense for anybody designing or implementing core infrastructure software. Decisions like that impose millions, if not billions of dollars in unnecessary costs on the world.

4 ms·

This sounds like a half-closed socket. I helped with WinRT socket API for Windows; we had to decide whether to support that or not. In the end, we couldn't co

by pedasmith 10y ago

wahern 10y ago
Huh? No realistic use cases? A half-closed socket is how you emulate EOF. It's like saying that EOF has no realistic use case; that _every_ protocol should implement a custom channeling and signaling mechanism at the application layer in order to get bidirectional streams, even though they're using TCP sockets. Now, many of the most popular protocols do that, but they do that because they're intended to be universally deployed and must deal with all the random pathological cases out in the wild. But if you don't have to worry about broken software, such as when you know there won't be broken proxies or routers in your path, then you can dramatically simplify many purpose-built protocols. As a practical matter most people can safely make that assumption. Most of the time it's cheaper and easier (in the grand scheme of things) to make the broken software shoulder the burden. Not everybody is writing software for Cloudflare or Chrome; and fortunately _most_ responsible vendors do a decent job at implementing standards correctly. I hope there's some confusion on your part or my part, and that you just didn't admit that WinRT was completely broken by design. That should be a hanging offense for anybody designing or implementing core infrastructure software. Decisions like that impose millions, if not billions of dollars in unnecessary costs on the world.