1 / 8

The End To End Argument In System’s Design

The End To End Argument In System’s Design. “The End To End Argument In System’s Design ”, Zaltzer et. al, ACM Transactions on Computer Systems, Nov. 1984. Error Handling.

drew
Télécharger la présentation

The End To End Argument In System’s Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The End To End Argument In System’s Design “The End To End Argument In System’s Design”, Zaltzer et. al, ACM Transactions on Computer Systems, Nov. 1984.

  2. Error Handling • Networks and Distributed systems are unreliable.Requests and replies can get lost, delayed or duplicated. Senders and receivers can crash. • Many, but not all of these issues can be handled by the communication protocol stack. • But if a call fails then the caller will need (error/exception) code to handle such cases.

  3. The End to End Argument • Saltzer et. al. 1981/84 posited the following argument. • The only true acknowledgment to the request for a file transfer is the reception of the complete file. • The application will have to include code to verify that the file was received correctly and to handle the cases where it is not. • Thus any attempts at increasing the reliability in the lower levels of the software can only be justified on the basis of increasing performance and not for correctness.

  4. Placing Functionality • “Functions placed at the low levels of a system may be redundant or of little value when compared to the cost of providing them at that low level.... low level mechanisms are justified only as performance enhancements.” • Distributed functions can be “…completely and correctly implemented only with the knowledge and help of the application standing at the endpoints of the communication system”.

  5. Problem Oriented Protocols • In general the end to end argument applies to where is the correct place to put functionality in a (distributed) system. • Problem oriented communication protocols are ones designed with the argument in mind and are tailored to the requirements and the operation environment of the problem at hand.

  6. Example FRAME RELAY

  7. FRAME RELAY • The data communications characteristics of the telephone network, and the processing power of DTEs, have changed since X.25 was specified. • Frame Relay takes this into account and provides a lightweight connection oriented, or “virtual leased line”, service at rates from 64kbps to 2.048 mbps (T1/E1). • Protocol handles framing, stuffing, virtual circuit multiplexing. • Performs error detection and congestion management. • Discards erroneous frames. • Users thus get a cheap, best effort, variable data rate connection.

  8. Stateless Servers • What are the different demands placed upon a communication protocol by • A stateless server which uses idempotent operations only? • A server with state and non idempotent operations?

More Related