Hacker News Reader

Comment by AlphaWeaver | Hacker News Reader

Why did Apple choose to use a networking protocol like HTTP to interface with two chips in the same hardware device?

The amount of money and eyeballs testing out an http stack far exceed that of a proprietary protocol.

The real question is why don't more rpc style protocols just use http?

But then the article states that they do non-standard/non-compliant things with HTTP/2 so they are using modified or new stacks...

"Apple appears to be using the HTTP/2 protocol only as a mechanism to maintain persistent connections, passing empty HEADERS frames to open new streams. This breaks section 8.2.1 of the HTTP/2 specification. We work around this by modifying the h2 module to allow empty HEADERS frames.

Apple’s use of the HTTP/2 protocol is also irregular for two other reasons. First, the HTTP/2 specification mandates that stream IDs must be created in a monotonically increasing order. However, Apple’s application endpoints appear to hardcode a handful of particular stream IDs for certain communications, which when opened do not conform to this monotonic ordering requirement. Second, client-server communication patterns often use multiple streams in unusual ways. For instance, heartbeat messages send requests over stream 1 and responses on stream 3."

Because http protocols give you lots of extra chances to screw things up.

https://justi.cz/security/2019/01/22/apt-rce.html

> Unfortunately, the HTTP fetcher process URL-decodes the HTTP Location header and blindly appends it to the 103 Redirect response:

gRPC, arguably the RPC framework with the most momentum behind it right now, uses HTTP/2 as it's transport

Apple tends to do that a lot. Back when I worked at Apple I had noticed the same thing. Two services that are sharing memory end up communicating over HTTP and I always found it silly.

> Two services that are sharing memory end up communicating over HTTP and I always found it silly.

why is that silly? It's be easy to migrate the services away from shared memory architecture when required, and http is well known and easy to use and debug.

If you've worked at Apple recently, I'm sure you'd know that "two services sharing memory" will probably stop doing that and end up isolated in different processes as soon as it's possible to do so…

My understanding is that there’s not much constant comunication going on, bridgeOS hands over control to macOS and that’s it. So HTTP is not a major overhead. But I could be wrong.

Don't tell Jonathan Blow about this unless you want to kill him.

I have no special knowledge but I assume since it is an encrypted-only protocol with significant research behind it.

Although many libraries only implement HTTP/2 with encryption, it never actually made the specification.

You are right-- good catch.

Simple explanation: maybe there were simply nobody who can come up with non-web programming? Webdevs are everywhere these days...

May be they implemented it with Electron and React?

Reply on news.ycombinator.com