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.
Google is working on creating a new protocol named QUIC to replace UDP
71–80 of 118 posts
Re: Google is working on creating a new protocol named QUIC to replace UDP
#72Re: Google is working on creating a new protocol named QUIC to replace UDP
#73Earlier quoted context omitted.
jbooth: Hindsight is a wonderful thing. The standards weren't terrible it was the entire concepts themselves and reflective of that era of computing. Most people thought XML was the future of the world and component architectures would be how all business software would be written. Little did we know. But I still use SOAP everyday with Java, .Net, iOS and JS clients. So the benefits of companies working on commons st…
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 interoperable stacks.
But at least there was a real reason, and serious value for a lot of developers. To compare, JSON doesn't even have a standard date format defined.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#74Earlier quoted context omitted.
>I'd go so far as to say that in these areas Google is serving as a model corporate citizen. Well that is a curious way to look at it. Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work. And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.
Sorry, but standards aren't formed in committees, they are standardized there. The right way to do this is: Put out your stuff, get others to implement it, everyone has experiences, get together and standardize based on those experiences. This is why folks like IETF rely on "rough consensus and running code" when standardizing. I always see this idea that companies should get together in a room and define protocols,…
Exactly, ask the ISO how well the standards specified by their OSI reference model [1] competed with TCP/IP et al. The only substantial remnant of the OSI network standardization process today is the generic concept of protocol layers.
Or see the HTML standardization process. Or a hundred other examples.
Standardization almost always follows implementation, not the other way around.
1. http://en.wikipedia.org/wiki/OSI_reference_model#Examples (see the "OSI protocols" column and compare to "TCP/IP protocols")
Re: Google is working on creating a new protocol named QUIC to replace UDP
#75Earlier quoted context omitted.
> It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java. I would really love to hear how you could possibly believe otherwise.
The language Java is simpler than the language Python or Ruby. Fewer keywords, those keywords do fewer things. Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations. I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be conven…
BrainF##k has even fewer keywords than Java, that doesn't make it simple.
I understand your point. Ruby and Python both have dynamic behaviour which makes it difficult to predict ahead of time what will happen when a program is run. In practice, however, the full range of possibilities is never exercised. It's not enough to look only at the language specification when you make these generalizations.
EDIT: TL;DR, essentially what matters is not the complexity of the language, but the complexity of programs written in the language.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#76I'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…
> Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs... > So - surprise! - you have no choice but to design a TCP clone. Some use cases don't really want TCP or a TCP clone, for example multi-player games might only use a semi-reliable loss detection system which has ACK's but does not attempt retransmission on failure to deliver. This works a lot better than TCP…
The really sad thing about this though is that "the internet" no longer works for stuff which isn't TCP. I guess it does, but not for your whole target market.
The lowest common denominator is users behind an NTLM proxy. Mass market products don't generally work unless they have a fallback which is "I can make it tunnel through proxies". Which is HTTP or CONNECT :( Which means no teams will do something which isn't TCP anymore, since it's not a thing they can tunnel :( Interested in counterexamples though.
This is the same reason why a UDP replacement is a great idea but a waste of time for most people developing a product. This makes me sad.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#77Earlier quoted context omitted.
Could it have been your NAT which terminated the connection due to inactivity ? Quite a few stacks have implemented RFC5961, which should make this attack rather challenging. (Though, I totally agree with the fundamental problem).
PREFIX: this is going to sound really cynical. Also, I haven't read RFC5961, so thanks :) Yeah, actually it might have been. But I prefer to give HN the benefit of the doubt. Umm I try and be gentle. But let's talk about the fundamental problem, since you appear to understand it. TCP-RST DoS is like the worst denial of service ever, since it has such massive negative amplification. You're spending like something like…
> fake ipsec traffic
..., most of it, is filtered out by the replay protection at virtually no processing cost. The HMAC verification is not exactly a CPU killer either, even less so if there's some sort ASIC/accelerator involved, which won't be that unusual if there is an IPsec involved.
To not multiple the comments - what I said above about a single TCP packet obviously implies being on the route between the parties.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#78This 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…
>If Google does it right, maybe it'll force OS developers to wake up and rethink the increasingly clunky and antiquated BSD sockets API that is the source of many of TCP's woes and finally modernize the network stack for the fiber era.
WinRT don't ever has BSD sockets.
Re: Google is working on creating a new protocol named QUIC to replace UDP
#79Earlier quoted context omitted.
> It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java. I would really love to hear how you could possibly believe otherwise.
The language Java is simpler than the language Python or Ruby. Fewer keywords, those keywords do fewer things. Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations. I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be conven…
The keyword count thing is easily refutable: Python has 38 keywords, Ruby has 41, Java has 50.
http://en.wikipedia.org/wiki/List_of_Java_keywords http://docs.python.org/3/reference/lexical_analysis.html#ide... https://github.com/ruby/ruby/blob/trunk/parse.y (grep for reswords)
I'm undecided whether Python/Ruby or Java are simpler.
At least to me dynamic typing seems much simpler than static typing: from a very very pragmatic view that just means no compile-time checks (?), and I'm not that good with Ruby, but I'd consider Pythons type system much simpler than Javas (Python has none of: primitive types, null, arrays, interfaces, visibility (well, there is name mangling for __...), enums, final/abstract, the checked/unchecked mess (look up what the correct way to catch exactly: all checked exceptions is!), casting, generics and everything that comes with it: have a look at the index at the left side of http://docs.oracle.com/javase/tutorial/java/generics/index.h... -- but to be fair Pythons type system has a couple of nontrivial features (metaclasses, multiple inheritance, ...) too)
Python/Ruby have a lot of very useful language features which make the languages much less of a pain to use than Java (the language), but for any meaningful comparison of language complexity you'd surely also have to consider the intricacies of the underlying VMs. The Java VM is quite complex and also quite powerful. For simple programs that don't require high performance or efficient memory management or whatnot that might not matter much though.
[Now, after having written this, I don't think its possible that any of the three languages is strictly simpler than any of the other ones.]
Re: Google is working on creating a new protocol named QUIC to replace UDP
#80Earlier quoted context omitted.
This. The point is not what they are doing, it's what they could do.
A big company will always have the potential to do harm. If it's not about what they're doing, but what they could do, then any company that has influence in a market needs to be taken down.
I'm not against companies having influence; the first thing I said was that I was all for innovation and what's the point of innovating if you won't be heard?
The point is that Google are in, not just a position of influence, but a position of control. Google don't need to seek the acceptance of the community at large for SPDY to be useful to them. This is a very different standpoint from, say, Mozilla.