31–40 of 118 posts
I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.
I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.
Each individual component is a sensible step forwards, but there's no doubt that Google could choose to do some pretty anti-competitive things if they wanted, and in the future there will always be different, more short-term, management in charge
Earlier quoted context omitted.
Care to point me to some sources on these limitations? I'm just curious.
I think they're talking about this: Not as SPDY as you thought : http://www.guypo.com/technical/not-as-spdy-as-you-thought/ The guy seems to know what he's talking about, and has actually run some tests but the test setup seems kind of weird. Effectively he's saying "if you only change HTTP to SPDY and make no other changes, then it's 3% slower (though more secure)" or "if you only change HTTPS to SPDY and make no ot…
The biggest challenge is optimising for SPDY is different to optimising for HTTP and so many of the test sites may have behaviours that aren't optimal for SPDY.
In addition to Google, Facebook and Twitter are/have deploying SPDY so I think we can be sure it has benefits.
Earlier 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.
Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)
H.264 and WiFi standards are recent examples of a lot of companies working together.
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…
"Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet."
I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption thingy you use. Otherwise, any modern TCP stack should be able to reject blind FINs or RSTs as out-of-sequence.
Generally, the reason people avoid TCP-over-TCP is not DoS, but basically "timer fights", as per: http://sites.inka.de/~W1011/devel/tcp-tcp.html. That said, everything-over SSL is still popular for practical reasons, such as clientless VPNs which need to work around proxies, firewalls etc.
Earlier 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.
Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)
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…
Some solutions to this use tcp to do the resetting of the connection.
It's about time, too. Certainly user-level substitutes for TCP are not a new idea (I've worked a good deal with UDT), but this the first one to my knowledge that has the weight of something like Google behind it.
There are a lot of advantages to doing this as the user level with UDP as well. Not needing to install a kernel module, for one. But also P2P rendezvous connections through NAT with UDP (we wouldn't even need to wait for router manufacturers to adopt anything), better control over protocol options without going through the kernel, custom congestion control algorithms, finer control over buffers (mmap'd files as buffer for file transfers anyone?), etc.
I'd much rather see this at the kernel level, but TCP as it's implemented on most systems has too many issues on modern networks, and most acceptable user-level solutions (ugh, parallel streams) are really terrible hacks. 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.
TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp.
Some questions: Why replace UDP? Why not work on top of UDP? There must be a reason for this. What about multicast?
These use cases spring to my mind: real-time data and multi-player action games, perhaps even streaming media. TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp. Some questions: Why replace UDP…