最近做的工具需要實現串口轉UDP中間件，中間件與下位機通過RS232通訊，與接收服務器通過UDP通訊。
在傳輸過程中出現問題如下：
1. 通過PC機安裝的虛擬串口進行調試，接收程序完全正常。
2.與下位機進行通訊測試，常規短報文接收都完全正常，但是在傳輸圖片分包文件（包總長度：545）時出現報文內部分字節丟失的問題。
經過不斷測試，發現：
1. 下位機發送的報文長度爲545，無異常；
2. 串口轉UDP轉發過程完全正常；
3.中間件的串口接收出現問題，原本545的報文接收到後會變成540、542、543等，總會丟失幾個字節；
折騰了一天終於找到原因，是由於在Delphi下使用的SPCOMM組件默認開啓了Inx_XonXofFflow、TxContinueOnXOff、Outx_XonXoffFlow三個屬性。
將這三個屬性值設置爲FALSE後測試，報文接收正常，轉發也正常，問題解決。
經過查找相關資料，對該三個屬性的解釋如下（以下內容轉載自http://blog.csdn.net/jinshaopu/article/details/4646791）：
最近幾天完成了BiasDAC的程序編寫。調試的過程還算比較順利，除了幾個有點bt的小問題。其中一個困擾了我兩三天的時間，今天上午終於將其解決。
由於BiasDAC是用RS232 Serial Port通信的，延用之前的程序，使用了Delphi的SPComm控件。在之前的使用中，SPComm控件一直工作正常，使用的是一般的string進行消息的傳遞。
而BiasDAC由於通信協議的限制，消息的發送使用的是hex方式，會用到從0x00到0xFF所有的這些字符。在調試中發現，發送0x11和0x13之後，SPComm的工作就會不正常。
首先是0x11發送之後，返回的0x11消息會被忽略；其次0x13發送之後，只能返回很有限的消息，而且似乎Serial Port就此關閉，如果再發送消息，就會造成Serial Port失去響應，只能通過重新啓動計算機才能恢復。
後來上網上查詢，原來不能正常處理0x11和0x13的問題早就存在，原因是SPComm空間中兩個屬性的存在。
OutX_XonXOffFlow/InX_XonXoffFlow：這個屬性是指進行發送/接收時的軟件握手標誌，兩個握手信號之間的數據被認爲是通訊數據，收到握手信號後，通訊就中止了。
FOutx_XonXoffFlow := True;
FInx_XonXoffFlow := True;
FXoffChar := chr($13);
Comm.Outx_XonXoffFlow:=False;
默認的初始化中，這兩個屬性是默認開啓的。
XOffChar/XOnChar：這是指握手的字節，默認的初始中，有
FXonChar := chr($11);
至此，真相大白。0x11，0x13被佔用爲通訊握手信號，自然不會得到正確的處理。
問題找到了，解決也很容易。只需要在Comm的初始化中，自己定義
Comm.Inx_XonXoffFlow:=False;
關閉軟件握手功能即可。在一般通訊中，硬件已經具備了握手功能，所以也不會影響到正常的Comm通訊。
以下內容轉載自：
http://hi.baidu.com/firebirdrui/item/fbfe420bd16843e0f55ba66f
COM串口傳輸文件
spcomm 控件
1. ReadIntervalTimeout屬性決定什麼時候觸發Comm1ReceiveData事件，也就是接收數據事件，例如設爲100ms，那麼在100毫秒內接收端會這段時間的數據當成一個包的數據，並觸發接收事件。超過這100ms的數據成爲另一包的數據。
2. 傳輸文件是有一個奇怪的顯現，如果是txt文件的話，那麼接收到的字節數是正確的，如果是doc，exe等文件，接收到的字節數是錯誤。當把接收端outtx_xonxoffflow屬性值改成false以後，此問題得到解決,經試驗inx_xonxoffflow屬性對次沒影響，而且發送端的這兩個屬性跟此情況也無關係
3. Spcomm應用的核心在於主線程、讀線程和寫線程之間的消息傳遞機制，而通信數據相關信息的傳遞也是以消息傳遞的方式進行的。在使用Spcomm進行串口通信編程，除按照說明使用外，還需要特別注意以下兩個問題。
首先，Spcomm是通過ReadIntervalTimeout屬性的設置，來確定所接收到的數據是否屬子同一幀數據，其默認值是100ms,也就是說，只要任何兩個字節到達的時間間隔小於1OOms，都被認爲是屬於同一幀數據，在與單片機協同工作時，要特別注意這個問題[2]。
另外，Spcomm的默認屬性設置是支持軟件流控制的，用於流控制的字符是13H(XoffChar)和11H(XonChar)，當單片機以二進制方式發送數據時，必須要禁用Spcomm對於軟件流控制的支持，否則，在數據幀中出現的13H，11H會被Spcomm作爲控制字符而加以忽略。