数据结构
网络
关系数据库管理系统 (RDBMS)
操作系统
Java
MS Excel
iOS
HTML
CSS
Android
Python
C语言编程
C++
C#
MongoDB
MySQL
Javascript
PHP
物理学
化学
生物学
数学
英语
经济学
心理学
社会学
服装学
法学比较并分析任何两种主要的报文传递系统变体
让我们讨论以下两种类型的报文传递系统：
客户端-服务器报文传递
考虑一个尝试从文件系统读取数据的应用程序。这意味着应用程序是向服务器请求数据的客户端。这种客户端或服务器模型引入了许多与报文传递相关的进程状态。
最初，服务器必须等待来自其他系统的报文到达。此时，服务器被称为接收阻塞状态。
接收到报文后，服务器进入就绪状态，并且能够运行。假设它是最高优先级的就绪进程，它将获得CPU并执行一些处理。由于它是服务器，它会查看收到的报文并决定如何处理。
在某些时候，服务器将完成报文指示的任务，然后向客户端发送回复。
现在让我们转向客户端。客户端一直运行并消耗CPU，直到它决定发送报文。客户端根据它发送报文到的服务器的状态，从就绪状态变为发送阻塞或回复阻塞状态。
通常，我们会看到回复阻塞状态比发送阻塞状态更常见。因为回复阻塞状态意味着：
服务器已接收到报文并正在处理它。在某个时刻，服务器完成处理并将回复发送给客户端。客户端被阻塞，等待此回复。
将其与发送阻塞状态进行对比。
服务器没有收到报文，因为它首先忙于处理其他报文。当服务器开始接收客户端报文时，我们将从发送阻塞状态变为回复阻塞状态。
网络分布式报文传递
让我们继承网络的特性：与其他系统相比，它们可以更轻松地实现网络分布式。但我们发现最有用的好处是，它们允许你以一种很好的、模块化的方式测试软件。
我们可能正在处理大型项目，其中许多人必须提供不同的软件部分。当然，这些人或早或晚会完成工作。
通常，它在两个阶段存在问题：
从定义时的概念开始，很难决定一个人的开发工作在哪里结束，另一个人的开发工作在哪里开始。
然后在测试或集成时，不可能进行完整的系统集成测试，因为所有部件都不可用。
概念的各个组成部分可以很容易地解耦，从而实现非常简单的设计和相当简单的测试。
如果我们想从现有范例的角度考虑这个问题，它类似于面向对象编程 (OOP) 中使用的概念。
142 次浏览
