If I use an HTTP 1.0/1.1 with PacketZoom, I'll be communicating on the internet with HTTP 1.0/1.1 over PacketZoom?
What if I want to communicate on the internet with other protocols such as WebSocket, SPDY, or HTTP 2.0? Does it work the same way?
11–14 of 14 posts
If I use an HTTP 1.0/1.1 with PacketZoom, I'll be communicating on the internet with HTTP 1.0/1.1 over PacketZoom?
What if I want to communicate on the internet with other protocols such as WebSocket, SPDY, or HTTP 2.0? Does it work the same way?
The discussion here, while short, has been much more informative than the site itself. I don't see any good reason to dumb-down the site like that - you're selling a protocol layer, so you're not going to have any non-nerdy customers!
Why are resumable downloads done in that layer? I have no trouble with downloads resuming across network switches when handled by higher-level protocols like chunked HTTP or even FTP.
Similarly, why would you even think about bundling multiple resources in one transfer at that level? Surely that's a higher level thing (like HTTP/2.0), and thus independent of transport? There appears to be a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer.
It all sounds very interesting, however, the tone of the web site comes across like some crappy download accelerator. When you follow the "nerdy details" link you don't get anything meaningful, just bland assurances and pretty animations, i.e. entirely non-nerdy. Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...",…
Thanks. I'll take this positive beginning at face value :-)
"Nowhere do I see basic technical info like "It's a new IP transport protocol used in place of TCP", or "It's compatible with existing networks because...", or "It's (better than|different to) (HTTP/2.0|QUIC|SPDY) because..."
I'm sorry if the material on the site is not technical enough for your taste. We've just launched and consider the site and the blog a work in progress. (Follow us on twitter at @packetzoom and me personally at @IAmChetanAhuja for updates).
Having said that, our customers are not necessarily people following the network protocol worlds closely. The stuff that you find "bland" and "pretty" is actually very helpful for a large portion of our target audience.
Now of course, those who click on the "Learn" link and don't find enough in-depth info are welcome to, and do, contact us directly. Every single mail we get on info@ or support@ addresses is read by a human in our (rather small) team and yes, we respond. Just as I'm responding to more detailed technical questions here.
"You're selling a protocol layer, so you're not going to have any non-nerdy customers!"
No we're not selling "a protocol layer". We're selling a drop-dead simple way to speed up downloads. Some of our customers are more interested in details of the protocol than others. But the majority of them want their apps to be fast and couldn't care less about, or even want to know about QUIC/SPDY/HTTP2.0 or whatever. Their questions are more like -- How easy is it to integrate? (very). Do I have to rewrite my code? (No). What do I have to change on the server side? (nothing).
And those of our customers who do want to go in-depth into details of the technology, do. They just talk to us and we explain what we're doing to the extent it doesn't reveal trade secrets.
"a lot of layer-leakage going on - not that it's necessarily bad, but the reasons for it need to be clearer"
This seems to be the crux of your issues with what we're doing. The reasons are ultra clear to us. Apps are faster and users are happier. That the only thing that matters.
We've found that merging layers allows us to handle, say, out of order delivery or dropped packets more smartly and more naturally. For far too long, user experience has been held hostage to diktats from the ivory tower. It's about time we start thinking from the ground up to create technology suited to what the users needs and not because we want to maintain some platonic ideal of "layer separation".
So, if I understood correctly: If I use an HTTP 1.0/1.1 with PacketZoom, I'll be communicating on the internet with HTTP 1.0/1.1 over PacketZoom? What if I want to communicate on the internet with other protocols such as WebSocket, SPDY, or HTTP 2.0? Does it work the same way?