本文探讨了协议在软件系统中的作用及其实施过程中可能遇到的模糊性问题。文章强调了为确保客户端与服务器间的完全兼容性，消除这些模糊性的必要性，并讨论了在基于现有操作系统创建兼容行为时面临的挑战。
Protocols are rules about two cooperating parties, such as a program and its underlying operating system, or a Web client and a Web server. For example, POSIX is a protocol for system service calls on the *nix platforms, and HTTP is a protocol for Web clients
to access Web servers.
As with regular function/method calls, an interaction in a protocol also has its prerequisites, post-conditions, input and output. Typically a protocol will specify all these in a descriptive way, however, descriptions may contain ambiguity.
When implementing a protocol, ambiguity can lead to misunderstanding, making client and server not fully compatible. To avoid this, protocol creators always try to eliminate such ambiguities, so that program implementers can avoid such incompatibilities.
Similarly, when implementing an operating system behavior (such as creating another compatible operating system, or creating an emulation system) based on an existing operating system, the process of modeling takes a lot of effort. Behavioral compatibility is required if we want to make all depending applications run on it without issues. Otherwise, applications that expect to handle an exception in one way may see the exception in another way, and thus being unable to process it.
The happy path is relatively easy to implement--when there is no error, the logic for operating system APIs are gone through, which is straightforward. API documentation can help us implement happy paths. But for behavioral compatibility, we need to investigate the source platform behavior in error situations by experimenting. This takes a lot of effort. As a payback, through this way, applications can run reliably on the new platform.
As with regular function/method calls, an interaction in a protocol also has its prerequisites, post-conditions, input and output. Typically a protocol will specify all these in a descriptive way, however, descriptions may contain ambiguity.
When implementing a protocol, ambiguity can lead to misunderstanding, making client and server not fully compatible. To avoid this, protocol creators always try to eliminate such ambiguities, so that program implementers can avoid such incompatibilities.
Similarly, when implementing an operating system behavior (such as creating another compatible operating system, or creating an emulation system) based on an existing operating system, the process of modeling takes a lot of effort. Behavioral compatibility is required if we want to make all depending applications run on it without issues. Otherwise, applications that expect to handle an exception in one way may see the exception in another way, and thus being unable to process it.
The happy path is relatively easy to implement--when there is no error, the logic for operating system APIs are gone through, which is straightforward. API documentation can help us implement happy paths. But for behavioral compatibility, we need to investigate the source platform behavior in error situations by experimenting. This takes a lot of effort. As a payback, through this way, applications can run reliably on the new platform.
扫一扫
5784
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
