Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Comment Re:Hrmm (Score 1) 249

It shouldn't be any worse for you than real-life is. I mean, when you look down the street and see a car approaching, does it look like a 3D scene to you? Probably. The eye with bad vision doesn't have to be able to focus clearly on the image for the brain to process the 3D aspects properly. The good eye provides the focus and the bad eye (even though the image is blury) is used as a crutch by the brain to provide the sense of depth. The image your brain ultimately composites will appear to be in-focus and in 3D.

The same would be true of these shutter glasses. It doesn't matter if the one eye is getting a blury picture, your brain is already trained to combine that blury picture with the in-focus picture to get a nicely composited 3D image.

If the entire real-world seems flat to you, then yeah, maybe you are screwed, but otherwise you should be fine.

Comment Re:fairness (Score 1) 872

Having written protocol stacks on top of UDP before, I can tell you that original poster is spot on. The reason the internet works is because the vast majority of the traffic is all sharing a common protocol (in this case TCP) for the reliable transport. TCP as a protocol is well proven to be fair to other TCP connections on the network. I wrote a TCP Reno like algorithm on top of UDP once that had a few enhancements over TCP to make it even better. TCP can't do these enhancements because it needs to remain compatible. Once I had that proprietary protocol stack in place, it was super-easy for me to tweak the parameters to the protocol to make it as friendly or unfriendly to TCP as I wanted.

The basis for sharing bandwidth is that if both connections employ the same algorithm for exploring and scaling to available bandwidth, then the competing connections will each settle in on a fair-share of the bandwidth. If however, one of the connections is using a different algorithm, then it's entirely possible that it will either get starved out by the other connections, or squash the other connections, taking more than its fair share. For example, if I simply change my protocol to tolerate moderate packetloss without scaling back the flow-control window size, I can effectively starve out any TCP connections on the same pipe in favor of me stealing all the bandwdith.

No matter how careful they are with their proprietary protocol, it is quite unlikely that they are going to be able to continue to be fair relative to TCP connections. And that reality is what is going to mess up the internet.

Now, the truth is that they are probably actually doing themselves a disservice. When routers get busy, they have a tendency to drop UDP traffic instead of TCP traffic. The reason for this is dropping TCP traffic does them little good, since they know for a fact that the packet will just get sent again. Dropping UDP traffic on the other hand often doesn't follow this rule, since UDP is often used for unreliable transfers, whereby the lost data is not resent (usually because it would be too out of date to have value by the time it is resent). If they switch these file-sharing networks to UDP, while it may seem to work well in the short term, it makes it very easy for the ISP's to simply dump UDP traffic in bulk if the pipe is getting full.

Short term the UDP may force out the TCP connections, but the ISP's won't tolerate that for long and it is really quite easy to just prioritize TCP over all UDP.

Slashdot Top Deals

Save energy: Drive a smaller shell.

Working...