通訊協議設計
用C語言肯定可以實現！要先在接收端的單片機處理設定好，就是你收到了什麼數據，要判定數據是否正確，要是正確的話，就要回復什麼數據；不正確就不響應。你可以看看485通信的例子。
『貳』 在計算機網路中,( )是為計算機網路相互連接進行通信而設計的協議。 AHTML BIP
HTML是網頁協議，IP是通信
『叄』 請問485通信協議怎麼寫485晶元的的外圍電路怎麼設計謝謝！
我不知道您是想知道從機的外圍電路 還是主機的外圍電路，我給您看一下我參考的兩種電路圖，使用起來很方便。主機也可以直接用他們的小主機，都不用自己做了。從機自己設計一下就可以了
『肆』 如何設計客戶端與伺服器雙向通信協議
1.
報文頭：
l
版本號：
10個字元，以開頭，例如：Ver1.0.0.0＝Ver1000。
l
報文類型(命令字)：
最長不超過20個字元。
l
報文驅動者：
客戶端（當前登錄的帳號），服務端（當前伺服器名）（最長不超過20個字元）。
l
有無參數指示器：
當有參數時，指示器為1，當無參數時，指示器為0。目的是加快解析速度。
l
報文長度：
最長不超過10個字元
l
參數體：
長度可變，但是報文頭＋參數體不超過2K位元組，（相當於2048個char型數據，其中連命令字之間的「，「也包括在裡面。）參數與參數之間應用「，」隔開，參數體最大長度為1024個位元組，相當於1K
l
整體報文格式：
版本號，報文類型，報文驅動者，參數指示器，報文長度，Value（參數1，參數2，。。。。。。。）
例如：
ABC伺服器認證請求的報文：
Ver1000,Login,ABC,0,報文長度,Value（）
ABC客戶端登錄的報文：
Ver1000,Login,ABC,1,報文長度,Value（賬號，密碼，IP地址）
l
報文結構體：
Struct
Server/CustomMessage
{
char
m_cVersion[10]; //版本號
char m_cCommandType[20]; //報文類型
char m_cDriver[20]; //報文驅動者
char m_cValueSwitch; //參數指示器
char m_cMessageLen[10]; //報文長度
char m_cInputValue[1024]; //參數體
}
2.
具體的報文
定義：－＞：表示發向那裡。
為了明了，以及方便，直接將參數填入結構體內。
設定伺服器為ABC，客戶端為CDE，Sizeof返回值為字元串。
在「」內表示值為字元串
參數體以Value開頭的字元串。
客戶端的登錄與認證
（命令字與參數）
1、 伺服器－＞客戶端：要求客戶端把賬號、密碼等信息傳過來。
GetLogin（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「GetLogin」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
2、 伺服器＜－客戶端：客戶端上傳賬號、密碼等信息。
Login（賬號，密碼，IP地址）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Login」;
m_cDriver=「CDE」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=「Value（賬號，密碼，IP地址）」;
}
3、 伺服器－＞客戶端：錯誤提示，表示賬號錯誤，一般為無此賬號。
AccountError（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「AccountError」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
4、 伺服器－＞客戶端：錯誤提示，表示賬號對，但密碼不對。
PasswordError（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「PasswordError」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
5、 伺服器－＞客戶端：錯誤提示，表示帳號被封，請和管理人員聯系。
BlockAccount（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「BlockAccount」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
6、 伺服器－＞客戶端：錯誤提示，表示已有相同的帳號登陸。
HaveSameAccount（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「HaveSameAccount」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
7、 伺服器＜－客戶端：客戶端已顯示錯誤提示，並將自己與伺服器斷開
ErrorMsgReceive（）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「ErrorMsgReceive」;
m_cDriver=「CDE」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=NULL;
}
8、 伺服器－＞客戶端：客戶端已通過伺服器的認證，伺服器向客戶端發送帳號，一次最多40個，估計1K左右。
SendCustomList（客戶端的賬號1，客戶端賬號2，。。。。。。。）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomList」;
m_cDriver=「ABC」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（客戶端的賬號1，客戶端賬號2，。。。。。。。）」;
}
9、 伺服器＜－客戶端：表示40個賬號已收到
SendCustomOk（）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomOk」;
m_cDriver=「CDE」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=NULL;
}
10、
伺服器－＞客戶端：表示伺服器把當前已接入進的所有客戶賬號發送完畢
SendCustomEnd（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「SendCustomEnd」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=NULL;
}
11、
伺服器－＞客戶端：向當前已連接上的所有的客戶端發送刷新消息，客戶端和伺服器會重復9、10、11的動作。
FlashCustomList（）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「FlashCustomList」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（客戶端的賬號1，客戶端賬號2，。。。。。。。）」;
}
12、
伺服器＜－客戶端：表示向某個客戶發送消息。
Message（對方客戶端帳號，自己客戶端帳號，客戶信息）
struct CustomMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Message」;
m_cDriver=「CDE」;
m_cValueSwitch=1;
m_cMessageLen=sizeof(CustomMessage);
m_cInputValue=「Value（對方客戶端帳號，自己客戶端帳號，客戶信息）」;
}
13、
伺服器－＞客戶端：轉發某個客戶端的消息給另一個客戶端。
Message（對方客戶端帳號，客戶信息）
struct ServerMessage
{
m_cVersion=「Ver1000」;
m_cCommandType=「Message」;
m_cDriver=「ABC」;
m_cValueSwitch=0;
m_cMessageLen=sizeof(ServerMessage);
m_cInputValue=「Value（對方客戶端帳號，客戶信息）」;
}
『伍』 如何知道別人設計的電路板上的通信協議
大致可以看使用的晶元，根據晶元型號判斷什麼協議。
一般每一款晶元都有自己的協議支持描述。
比如網上拆卸蘋果手機的過程，就可以通過晶元來判斷只是什麼通信協議。
『陸』 通信協議軟體設計為什麼很困難（三）
計算機技術和通信技術的融合是目前通信協議軟體的必由之路。大的通信公司往往是通過招收大量的計算機專業人才來解決這個問題，在同一個開發團隊中，通信專家負責通信協議的設計和分析，而計算機專家負責協議軟體的實現。這對於我們這樣的高校團隊就比較困難了，只能通過讓同學在學習通信知識的同時，加強計算機軟體方面的訓練： 1）要熟悉實時操作系統系統的知識。協議軟體的各種功能都是建立在操作系統的基礎上的，特別是在通信軟體中多個任務同時工作，所以操作系統中的線程管理、線程間通信就變得特別重要。 2）要熟悉計算機網路的知識。核心網已經全都採用基於IP的架構，不了解計算機網路的知識，寸步難行。 3）要熟悉軟體工程的知識。通信軟體體系龐大，必須通過團隊開發來解決，而這都需要軟體工程的思想、技術和工具來支撐。 4）要熟悉編程語言的知識。軟體無線電和軟交換的興起，使得大量原本採用硬體實現的功能現在都要通過軟體實現，軟體開發在系統中的作用愈來愈突出，所以熟練地掌握一門甚至多門編程語言已經變得非常必須。 5）要熟悉各種開源工具軟體。開源文化的興起，給研究工作帶來了新的機遇，我們可以不必事事從頭做起，但是開源也帶來新挑戰，你必須熟悉開源工具的各種工具，必須接收開源社區自由開發所帶來的工具繁多，文檔匱乏和零碎所帶來各種問題。 6）要學習數據結構的課程。通信軟體中充斥著各種隊列、圖、樹之類的描述，如果不熟悉數據結構，對於這些復雜的對象就無從下手。 7）要學習編譯原理的知識。當然，用到這一步就比較高深了。通信軟體的工作量往往是巨大的，為了提高效率，許多大公司都或多或少地採用一些自動工具，而編譯原理就是開發這些自動工具的基礎。我們項目中就曾經自己開發過ASN.1的編譯生成工具。 想想一個通信的研究生要在兩年半的時間中，除了學習通信知識，還要學習這么多的計算機知識，再要完成研究工作，的確是一項艱巨的任務。
『柒』 如何設計一個網路游戲的通信協議和控制協議(在線急等啊，急！急！急！，求大神解答！！)
你這個問得太大了，光是建立伺服器就要說上很長時間，還要設計通信協議。建議去看看基本的TCP/IP程序編寫，C/S架構程序的編寫。
『捌』 如何設計一種串列通信協議
簡單的說要做一個協議，首先要考慮你的匯流排拓撲形式。是點對點的方式傳輸（是一主一從，還是兩個為對等的節點），還是一個主機下掛了多個從節點（節點和主機如何鏈接，是星形鏈接、樹形鏈接，還是匯流排型連接）。
如果是一主一從的點對點那是最簡單的。如果是兩個對等的節點或者一對多匯流排節點，那就需要考慮匯流排競爭、沖突、地址設計、超時處理等問題。
那最簡單的主從點對點來說（封閉式網路，即設備節點數確定，且非相設備協議不相同無法接入該網路）。
首先你的波特率設置，最好是所有節點都定一個波特率，有人做過不同波特率通信的，反正我沒玩過。而且波特率的大小要從你匯流排的數據量開銷、處理器/控制器的速度、應用的環境中電磁復雜程度、硬體設備的帶寬（頻率高了會不會受影響，導致丟包率增大，或影響其他設備）
然後一個幀開頭應該帶有幀標識，讓對方判斷收到的是數據幀還是應答幀。點對點通信，最少應該具備一個數據命令幀和應答幀。數據命令幀是包含主要設信息的，應答幀是告訴對方是正確否收到數據，如沒有，請重發。另外如果收的幀標識都不是這兩種的，就說明可能匯流排出現問題/受干擾/接入其他未知設備。
其次考慮你傳輸的數據量有多大，是否需要數據包定長。如果傳輸的數據時而多（十幾/幾十個個位元組），時而少（不到一個位元組），那就不能定長。這樣的話就需要在第二第三個位元組（放幀標識的位元組前後）加上包/幀的長度信息。
然後是地址，雖然只有兩個點在面對面對話通信，但建議加上源地址和目標地址。這個只是建議，在點對點通信中可選。
之後應該加上一個序列號，用以表示為第幾次發送。比如說，我發了一次Hello給你，下一次應該發一個World給你，但你反饋應答幀說沒收到或者收到錯誤，然後我再發一次Hello給你，這時的Hello這幀中的序列號應為2了。
接下來是數據內容……
最後是校驗，CRC ……異或……什麼的，對前面所有的數據從幀頭到幀尾的位做數據校驗。防止傳輸過程中，任何一個bit出錯。
現在想到的就是這么點。吐個槽，記得當年我們一組人做鐵路信號設備的協議，研究院的人看了我們兩周想出來的協議後（基於RS584），說：協議是這么簡單就搞出來的么！沒試驗個一年的工夫都不敢說整出一個安全的強壯的協議來。
『玖』 通信協議的設計(c語言）
我和其他很多人以前分析過文曲星串口的協議
emsky.net上有文章，你去找找幾年前的帖子
『拾』 簡單談談自己通過實驗對TCP,HTTP協議的理解,以及對通信協議設計的一些看法.
這個可以從osi的七層模型角度來看。tcp和udp是傳輸層的協議，通常是用ip協議為回他們的承載層。答而在上面有 表示層 會話層 應用層。這最上面的三層可以統稱為應用層，在網路數據傳輸的過程中可以把它看成是數據date。http屬於應用層的協議，只有下四層的網路通了，才能有上層應用的成功使用。所謂的通信協議都處於不同的網路層次，他們的順序都是由數據封裝的順序來定的。就像你 寄送包裹時 填地址，先填省市區縣鎮街道 一樣。