Go back and reread my posts, I've given several concrete examples of how efficiencies can be gained. There's nothing fuzzy about it.
I did, the gains you mention are superficial. For example: peers can open more connections; clients don't have to deal with connection state; no three-way handshake; etc.
I don't believe you have a good case here:) I want to see something like a 20% improvement in, say, download time given the same network topology conditions, while still being able to avoid congestion well.
I'll give you that this is a tall order, and that we should probably be reading BT and TCP research papers to see what the state of the art does.
Of course, care must be taken not to overwhelm the inbound bandwidth of the peers with block requests. At present, most peers...
This seems like a lot of specialized little tricks and rules of thumb that aren't really simpler than what standard TCP-based clients do... again, I'm not convinced by the argument:)
The more I think about it, the more I believe that a BT protocol should be completely ACKless, with no attempt to retry or even track failed deliveries. Definitely not how TCP works.
That depends. I could view each TCP connection transferring one chunk as one packet. Then there is no ACK; if the connection breaks in the middle it times out just like the other method. I can also apply all the other connectionless tricks.
I can't see how anyone can't see that Bittorrent is fundamentally different than point-to-point data delivery protocols, and that there are lots of opportunities to exploit those differences to make a protocol that is more efficient AND better addresses congestion control.
This I would like to see. The fact that TCP sends around streams of data point-to-point is not much different from UDP, because each chunk (which is small relative to the whole file) can be viewed as a packet. Of course a multipoint-to-point protocol is different from a p2p one, but it must be built on a point-to-point primitive, be it IP, UDP or TCP. The TCP option is not that inefficient, because the three-way handshakes have negligible performance impact with large chunks.
So again, the efficiency gain won't come from some fuzzy "this protocol is designed from the start to be multipoint-to-point" philosophy, but from doing a better congestion control than TCP's, which loses during the slow-start ramp-up and the seesaw steady state phase with the 20% or so loss.
Because TCP is well-designed for bulk, delay-insensitive, point-to-point, in-order transfers.
The in-order delivery is so far the only extraneous feature mentioned in the discussion, so points for that:)
It's design doesn't consider a situation where the data is available from any of many hosts on the network.
Neither does UDP's. IP provides best-effort point-to-point service. What, are you going to use IP multicast? No, applications are going to do their own, TCP or not.
I still don't see a real, compelling reason to abandon TCP for BitTorrent; so far these are all just philosophical arguments without real gain. The only potential saving I can see is the 20% or so penalty due to the seesaw behavior of TCP during its congestion control stage.
However, it is the wrong tool for many modern applications.
Yeah, sure, anything not doing bulk or stream oriented transfers. So what?
My objection was to the naive canonization of TCP as an all-purpose protocol that's somehow magically superior to any protocol that the application can implement on its own behalf.
Point taken. By the same token, I defend TCP because there are good reasons for its seemingly inefficient design. There are 30 years of experience and academic research on TCP design. When evaluating any replacement protocol you have to ask yourself, would the Internet suffer a congestion meltdown if the *vast majority* of traffic switched to it? I can't take any TCP complaints seriously until I have a good answer to this question.
The developers of BitTorrent have long since passed the level of play where they're better off using TCP/IP
Why? BitTorrent is arguably exactly the application that should be using TCP--it does bulk, delay-insensitive transfers in enough quantity to cause congestion. Why in the world would you have BitTorrent use something else when it will turn out reimplementing TCP?
I think you are overreacting. Not every Easter egg is a flight simulator. For a mission critical product it might amount to a lighthearted message coming out of the debug console or something.
I'm not even sure about SMTP. Perhaps you could have built some public key encryption based system that authenticates the senders. And then the spammers figure out that they can send all the email they want anyway using zombie networks, and you're stuck with spam anyway in addition to an overcomplicated email system.
Of course, some clever kid could then come up with SMTP and have it take off because it is much easier to use:)
Let me add my own experience too, wait a long time for the electronics to dry. Once it looks *completely* dry, wait one more year. Then in 2010, turn the stuff upside down, and repeat the process. In 2011, set it on its one side. In 2012, the other side. God help you if your stuff has more faces than a hexahedron!
Dude! Which town is this and are they accepting new residents?
Re:Can we please talk about physics now?
on
LHC Success!
·
· Score: 1
Hear, hear.
How long until some results are known? IIRC one of the saddest outcomes of this experiment would be to find nothing new, because new bigger colliders would not get funded.
The garbage example is good. Yes the city will pick up a couch or two. But just try and dump all the furniture from a small office building on trash day and see how that works out for you. That is the kind of usage difference between casual and p2p users.
Slashdot Mirror
I know, we could use a bandwidth reservation protocol! Maybe you can be the first to donate some money to get the backbone providers to turn on RSVP :)
Ye Gods! Jon Postel must be spinning in his grave. It seems we are not doing enough to teach kids TCP/IP.
I did, the gains you mention are superficial. For example: peers can open more connections; clients don't have to deal with connection state; no three-way handshake; etc.
I don't believe you have a good case here :) I want to see something like a 20% improvement in, say, download time given the same network topology conditions, while still being able to avoid congestion well.
I'll give you that this is a tall order, and that we should probably be reading BT and TCP research papers to see what the state of the art does.
This seems like a lot of specialized little tricks and rules of thumb that aren't really simpler than what standard TCP-based clients do... again, I'm not convinced by the argument :)
That depends. I could view each TCP connection transferring one chunk as one packet. Then there is no ACK; if the connection breaks in the middle it times out just like the other method. I can also apply all the other connectionless tricks.
You can tell me, I work in the same place.
This I would like to see. The fact that TCP sends around streams of data point-to-point is not much different from UDP, because each chunk (which is small relative to the whole file) can be viewed as a packet. Of course a multipoint-to-point protocol is different from a p2p one, but it must be built on a point-to-point primitive, be it IP, UDP or TCP. The TCP option is not that inefficient, because the three-way handshakes have negligible performance impact with large chunks.
So again, the efficiency gain won't come from some fuzzy "this protocol is designed from the start to be multipoint-to-point" philosophy, but from doing a better congestion control than TCP's, which loses during the slow-start ramp-up and the seesaw steady state phase with the 20% or so loss.
The in-order delivery is so far the only extraneous feature mentioned in the discussion, so points for that :)
Neither does UDP's. IP provides best-effort point-to-point service. What, are you going to use IP multicast? No, applications are going to do their own, TCP or not.
I still don't see a real, compelling reason to abandon TCP for BitTorrent; so far these are all just philosophical arguments without real gain. The only potential saving I can see is the 20% or so penalty due to the seesaw behavior of TCP during its congestion control stage.
Yeah, sure, anything not doing bulk or stream oriented transfers. So what?
Point taken. By the same token, I defend TCP because there are good reasons for its seemingly inefficient design. There are 30 years of experience and academic research on TCP design. When evaluating any replacement protocol you have to ask yourself, would the Internet suffer a congestion meltdown if the *vast majority* of traffic switched to it? I can't take any TCP complaints seriously until I have a good answer to this question.
Why? BitTorrent is arguably exactly the application that should be using TCP--it does bulk, delay-insensitive transfers in enough quantity to cause congestion. Why in the world would you have BitTorrent use something else when it will turn out reimplementing TCP?
Next step: switch to raw sockets, and implement a TCP without congestion control. Filter that!
I suppose you have some other clever way to deal with congestion?
I think you are overreacting. Not every Easter egg is a flight simulator. For a mission critical product it might amount to a lighthearted message coming out of the debug console or something.
... external media bans DOD!
I am *expanding!* It is so much *squishy* to *smell* you!
Hah. That cheap trick doesn't work in the premium mazes on our MUD, because monsters wander around and pick stuff up.
And wifi was on the whole time? That's a really suspicious claim. WiFi parts can consume 100+ mW even while idle.
3D acceleration support, various binary-only drivers, flash player.
Also, it might take some time to tune browsers/JS engines on an arch with vastly different cache performance.
Of course all of this could get solved given some time.
Throw away the products of this process, and, now that they are "garbage", feed them back into the machine. Voila! Free energy forever.
I'm not even sure about SMTP. Perhaps you could have built some public key encryption based system that authenticates the senders. And then the spammers figure out that they can send all the email they want anyway using zombie networks, and you're stuck with spam anyway in addition to an overcomplicated email system.
Of course, some clever kid could then come up with SMTP and have it take off because it is much easier to use :)
Let me add my own experience too, wait a long time for the electronics to dry. Once it looks *completely* dry, wait one more year. Then in 2010, turn the stuff upside down, and repeat the process. In 2011, set it on its one side. In 2012, the other side. God help you if your stuff has more faces than a hexahedron!
hadron!
I'm sure that vendors are dying to satisfy the weird needs of those 20 people. :D
Bah, we had all this stuff on MUDs forever. All Diablo did was put a GUI on the mudlib.
Not that I am complaining, they are beautiful and well done games.
Two words: crystalline entity!
Dude! Which town is this and are they accepting new residents?
Hear, hear.
How long until some results are known? IIRC one of the saddest outcomes of this experiment would be to find nothing new, because new bigger colliders would not get funded.
The garbage example is good. Yes the city will pick up a couch or two. But just try and dump all the furniture from a small office building on trash day and see how that works out for you. That is the kind of usage difference between casual and p2p users.