101–110 of 118 posts
UDP is connectionless. How can we have encryption without a connection? Using a block cypher would be less secure than stream cyphers and the controversy could halt adoption.
It's possible: DTLS. Also CISCO uses UDP for their VPN solutions so go figure.
Google wants control, IMO.
I'd be interested in their reasons for not using DTLS, or improving DTLS. They actually use it for WebRTC.
Earlier quoted context omitted.
It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful. The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to…
>Why would you ever choose SOAP over a simple REST endpoint? I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interop…
This is more than merely UDP with encryption. Rather, this seems to be a reliable stream protocol that aimed at dethroning TCP. I don't think it intends to replace UDP. If anything, I would describe it as a user space replacement for TCP. It uses UDP, yes, but that's because UDP is about as close as you can get to IP at the user level. It's about time, too. Certainly user-level substitutes for TCP are not a new idea…
Also, why do we want to re-implement TCP in user space, when it still needs to traverse the kernel as a UDP packet, this doesn't have any of the benefits that netmap or PF_RING for example bring to the table where the software is doing the full stack and thus there is less latency involved.
QUIC as it currently stands will be sitting on top of UDP, so all packets traverse the kernel, get dumped to user space, user space parses it, and sends packets back, as UDP. All that extra copying, when with TCP in the kernel the kernel would be responsible for reassembling packets, would be responsible for ACK'ing packets, and stuff like that.
Also, mmap'd files as buffer for file transfers ... you are going to have to explain that one. There are already various zero copy mechanisms for sending files, such as sendfile().
As for new congestion control algorithms, great, sounds fantastic, but how much more of a nightmare is it going to be to get the parties to agree on a congestion control mechanism? We already have that problem now ...
Sorry, but I see a whole lot of complaining without any real data or information to back it up. [[citation needed]].
UDP is connectionless. How can we have encryption without a connection? Using a block cypher would be less secure than stream cyphers and the controversy could halt adoption.
Earlier quoted context omitted.
Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome. I'd go so far as to say that in these areas Google is serving as a model…
Having open-source implementation do not mean you're not going to "embrass and extend". It's a common misconception. If you're the only big player, that your stuff is open just means others can also implement your protocol. But since you're the only big player, they can't have their protocol. So you can make your protocol work for you, do things that will bring you more money, and have it open-source, AND force it up…
I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…
Actually, there are also "scavenger" congestion control algorithms that use leftover bandwidth. The most high-profile example is LEDBAT used by BitTorrent's uTP. uTP is indeed a TCP clone, but I had my chance to develop a protocol which was using LEDBAT and it was NOT a TCP clone at all (it later became IETF PPSP). So, TCP eating all the bandwidth is not an issue sometimes.
Hopefully they'd take a lot from djb NaCl ( http://nacl.cr.yp.to/ , which predates Google's NaCl and is unrelated). Transport security, endpoint multiplexing and endpoint mobility done right.
why does google need to come up with protocols? does the IETF and other processes in place for over a decade not work for them? I know nothing of the protocol (the link only mentions the 'cheeky' naming scheme and the source in the chrome tree); I'm merely commenting on googles motives...
I heard someone here in a express it this way at a techtalk when asked about the motive for doing things like SPDY (paraphrased):
"We want the web to be as fast as possible for EVERYBODY. So some of us are building things like SPDY since we can implement it both the server and browser for Chrome users. Meanwhile, other folks are working to make the web faster for non-Chrome and mobile users too (PageSpeed, our public DNS, paying people like Steve Souders to do performance research, etc.)"
Earlier quoted context omitted.
It's not just XML. Why would you ever choose SOAP over a simple REST endpoint? If you use SOAP frequently, have you used jaxb or jaxrpc? Those things were awful. The systemic problem, which isn't just hindsight, is that you had 6 corporate vendors, each with their own internal politics, in a room with cross-corporate politics, creating a standard. Of course it will be a bloated monstrosity. It's not just hindsight to…
>Why would you ever choose SOAP over a simple REST endpoint? I thought the obvious answer was always tooling. Point Visual Studio at WSDL, and immediately get IntelliSense and go to town. Take your easy "object oriented" designs, and pop them on the web, with less of the trouble of DCOM or CORBA, and more security. But of course it only works if the tooling is in place, and there was probably only a couple of interop…
Imagine doing SOAP entirely by hand, with a semi-complicated WSDL. It's a nightmare. Doing a RESTful service based on JSON data is not just not a nightmare, it's a breeze, with no need for any of the tooling you describe and with, in my opinion, absolutely no difference in API richness, interoperability, security, quality etc.