資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學比較並分析任何兩種主要的報文傳遞系統變體
讓我們討論以下兩種型別的報文傳遞系統：
客戶端-伺服器報文傳遞
考慮一個嘗試從檔案系統讀取資料的應用程式。這意味著應用程式是向伺服器請求資料的客戶端。這種客戶端或伺服器模型引入了許多與報文傳遞相關的程序狀態。
最初，伺服器必須等待來自其他系統的報文到達。此時，伺服器被稱為接收阻塞狀態。
接收到報文後，伺服器進入就緒狀態，並且能夠執行。假設它是最高優先順序的就緒程序，它將獲得CPU並執行一些處理。由於它是伺服器，它會檢視收到的報文並決定如何處理。
在某些時候，伺服器將完成報文指示的任務，然後向客戶端傳送回覆。
現在讓我們轉向客戶端。客戶端一直執行並消耗CPU，直到它決定傳送報文。客戶端根據它傳送報文到的伺服器的狀態，從就緒狀態變為傳送阻塞或回覆阻塞狀態。
通常，我們會看到回覆阻塞狀態比傳送阻塞狀態更常見。因為回覆阻塞狀態意味著：
伺服器已接收到報文並正在處理它。在某個時刻，伺服器完成處理並將回覆傳送給客戶端。客戶端被阻塞，等待此回覆。
將其與傳送阻塞狀態進行對比。
伺服器沒有收到報文，因為它首先忙於處理其他報文。當伺服器開始接收客戶端報文時，我們將從傳送阻塞狀態變為回覆阻塞狀態。
網路分散式報文傳遞
讓我們繼承網路的特性：與其他系統相比，它們可以更輕鬆地實現網路分散式。但我們發現最有用的好處是，它們允許你以一種很好的、模組化的方式測試軟體。
我們可能正在處理大型專案，其中許多人必須提供不同的軟體部分。當然，這些人或早或晚會完成工作。
通常，它在兩個階段存在問題：
從定義時的概念開始，很難決定一個人的開發工作在哪裡結束，另一個人的開發工作在哪裡開始。
然後在測試或整合時，不可能進行完整的系統整合測試，因為所有部件都不可用。
概念的各個組成部分可以很容易地解耦，從而實現非常簡單的設計和相當簡單的測試。
如果我們想從現有範例的角度考慮這個問題，它類似於面向物件程式設計 (OOP) 中使用的概念。
142 次瀏覽
