СorrectクローズTCP接続スローJavaの

Question

私はlogica smpp libを使用してESMEを書きますが、深刻な問題を持っています - をSMSCはESME [FIN、ACK]に送信するとき、ESMEは正しい答えはありません。ここで

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 

これを解決する方法は？このパケットを扱うことは可能ですか？どんなオファーも大歓迎です。クラスTCPIPConnectionで

Answer 1

、方法 - public ByteBuffer receive()あなたはこのような何か行う必要があります。ロジカlibにのようなフレームワーク/ライブラリを使用しての全体のポイントは、低レベルのAPI/TCPのFINレベルからあなたを隔離するべきである

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

Answer 2

を詳細、それ以外の場合、フレームワークを使用して追加する価値はありません。私たちはこの道を通ってきました。あなたが才能のあるTCPプログラマを抱えていない限り、TCPレベルでのこの作業のルートは生産的ではありません。

私はopensource SMPP libを見たことがあります。Cloudhopper（Twitterで作成され、後にオープンソース化されました）は、非常に大きなプラットフォームで年間使用されています。これは、堅牢で多くの主要通信事業者で実証されています。カスタマイズに使用できるサンプルクライアントがあります。接続管理：最初にSMPP接続（セッションごと）が行われたときに接続をキャッシュします。 submitSM PDU（SMSを送信する）を実行する際に、例外のタイプをチェックします。接続例外です。単純にSMPPセッション/接続を再バインドして再入力してください。 40秒を超えるような大量のインアクティビティがあると、SMPPサーバー/ SMSCが接続を捨てる可能性があります。再接続するには、次の2つのオプションがあります。a）次にPDUを送信し、再接続し、キャッシュを更新してからsubmitSm PDUを送信するか、b）これが優先されるオプションです。 enquireLink pDUを定期的に実行する別のスレッドを用意してください。たとえば、45秒ごとに接続がアクティブになっていることを確認します。enquireLinkおよびsubmitSM PDUは同じキャッシュされたSMPPセッション/ Connectionを使用します。もちろん、enquireLink PDUが切断された接続を検出した場合、再バインドを行い、共通のSMPPセッション/接続を更新する必要があります。私はこのアプローチが何年も前から複数のアプリケーションでうまく機能しているのを見てきました。