End-to-end principle: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
The end-to-end principle is a design framework for distributed | The [[end-to-end principle]] is a design framework for [[distributed system]]s. It counsels that the [[network]] should be kept as simple as possible and any necessary intelligence/{{risk|complexity}} be kept at the ends of the network - the entry points to it, in other words, as far as possible<ref>{{author|Lawrence Lessig}}, {{br|Code: Version 2.0}},126.</ref>. | ||
On a computer network, that would mean "application-specific" complexity would be in the communicating end-nodes of the network, rather than in intermediary gateways and routers, that comprise establish the network. | |||
That is, in your [[Macintosh]] before it plugs into the network, and not on the routers and switchers through which the cleverly assembled messages from your Macintosh make their dematerialised way. The packets of data that fly across the net courtesy of the [[TCP/IP protocol]] are very simple indeed. The machine that collects them and reassembles them for a user at the other end of the network (also, likely, a Macintosh) is also very clever. | |||
In the case of a transport, compare a railway, in which you don't need any particular kit to ride on the underground, beyond a ticket, but you are severly constrained as to when and where and how you get from a limited number of points, and a road network, in which it is up to you what kit you bring to the network (you could walk, cycle, or show up in a Lamborghini Murcielago — your choice) but you choose when and where you travel, which route you take, and your catalogue of starting and ending points is almost infinite. | |||
Consequences of this design philosophy: | Consequences of this design philosophy: | ||
*You can innovate on the network without bothering the network "owner". This avoids "strategic" behaviour by the network owner (such as interfering to stifle the innovation). | *You can innovate on the network without bothering the network "owner". This avoids "strategic" behaviour by the network owner (such as interfering to stifle the innovation). | ||
{{ref}} | |||
Revision as of 18:20, 11 January 2019
The end-to-end principle is a design framework for distributed systems. It counsels that the network should be kept as simple as possible and any necessary intelligence/complexity be kept at the ends of the network - the entry points to it, in other words, as far as possible[1].
On a computer network, that would mean "application-specific" complexity would be in the communicating end-nodes of the network, rather than in intermediary gateways and routers, that comprise establish the network.
That is, in your Macintosh before it plugs into the network, and not on the routers and switchers through which the cleverly assembled messages from your Macintosh make their dematerialised way. The packets of data that fly across the net courtesy of the TCP/IP protocol are very simple indeed. The machine that collects them and reassembles them for a user at the other end of the network (also, likely, a Macintosh) is also very clever.
In the case of a transport, compare a railway, in which you don't need any particular kit to ride on the underground, beyond a ticket, but you are severly constrained as to when and where and how you get from a limited number of points, and a road network, in which it is up to you what kit you bring to the network (you could walk, cycle, or show up in a Lamborghini Murcielago — your choice) but you choose when and where you travel, which route you take, and your catalogue of starting and ending points is almost infinite.
Consequences of this design philosophy:
- You can innovate on the network without bothering the network "owner". This avoids "strategic" behaviour by the network owner (such as interfering to stifle the innovation).