End-to-end principle: Difference between revisions
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| Line 2: | Line 2: | ||
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. | 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. | ||
===Examples=== | |||
'''Internet versus phone system''': In an old fashioned susbscriber dialling network you need to have the kit installed in your house before you can make a call, and you can call 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. | |||
'''Road versus rail''': 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. | |||
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}} | {{ref}} | ||
Revision as of 12:15, 14 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.
Examples
Internet versus phone system: In an old fashioned susbscriber dialling network you need to have the kit installed in your house before you can make a call, and you can call 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.
Road versus rail: 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).