Сorrect關閉TCP連接的投擲的Java

我使用logica smpp lib寫ESME，但有一個嚴重的問題 - 當SMSC發送到ESME [FIN，ACK]，ESME不回答正確。Сorrect關閉TCP連接的投擲的Java

這裏TCP轉儲：

2751.016216 ESME -> SMSC   SMPP SMPP Submit_sm 
2751.019818   SMSC -> ESME SMPP SMPP Submit_sm - resp: "Throttling error (ESME exceeded allowed message limits)" 
2751.136172 ESME -> SMSC   TCP 42265 > 5001 [ACK] Seq=1651885221 Ack=3959508692 Win=123 Len=0 
2774.588453   SMSC -> ESME TCP 5001 > 42265 [FIN, ACK] Seq=3959508692 Ack=1651885221 Win=32768 Len=0 
2774.741502 ESME -> SMSC   TCP 42265 > 5001 [ACK] Seq=1651885221 Ack=3959508693 Win=123 Len=0 
2821.032427 ESME -> SMSC   SMPP SMPP Submit_sm 
2821.033502   SMSC -> ESME TCP 5001 > 42265 [RST] Seq=3959508693 Ack=0 Win=32768 Len=22

如何解決這個問題？是否有可能處理這個數據包？任何優惠都歡迎。

來源

2012-03-23 Divers

opensmpp有一些嚴重的問題，我不記得當我們測試時這個特定的行爲是否是其中的一個，但還有其他showstoppers（如文本編碼的不恰當處理）。我們最終從頭開始重新實施smpp協議 – mitchnull 2012-03-26 09:58:42

在TCPIPConnection類，方法 - public ByteBuffer receive()你應該做這樣的事情：

    bytesRead = inputStream.read(receiveBuffer, 0, bytesToRead); 
        if (bytesRead == -1){ 
         //close connection here 
        }

來源

2012-03-28 06:32:14 Divers

使用框架的整點/圖書館像邏LIB應該是從低級別的API/TCP FIN水平隔離細節，否則使用框架沒有增值。我們已經走過了這條路，除非您擁有優秀的TCP程序員，否則這種在TCP層面工作的途徑並不會很有成效。

我已經看到開源的SMPP lib Cloudhopper（由Twitter製作，後來開源）在多年以來在一個非常大的平臺上使用。它在許多領先的電信運營商中穩健且經過生產驗證。它有示例客戶端，您可以使用它來自定義。連接管理：首次連接SMPP時（每個會話）緩存連接。在執行submitSM PDU（發送SMS）時，檢查異常的類型，它是連接異常，只需重新綁定並重新整合SMPP會話/連接。如果您的活動時間很長（比如超過40秒），那麼SMPP服務器/ SMSC可能會丟棄連接。要重新連接，有兩種選擇：a）下一次執行submitSM PDU時檢測陳舊連接，重新連接，更新緩存，然後發送submitSm PDU或b）這是首選選項。有一個單獨的線程定期執行enquireLink pDU - 例如，每45秒鐘一次，這將確保連接保持活動狀態。假設enquireLink和submitSM PDU使用相同的緩存SMPP會話/連接。當然，如果enquireLink PDU檢測到連接斷開，它應該重新綁定並更新公共SMPP會話/連接。我看到這種方法自多年以來在多個應用程序中運行良好。

來源

2015-07-31 11:02:05

Сorrect關閉TCP連接的投擲的Java

回答

相關問題