0

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

これを解決する方法は？このパケットを処理することは可能ですか？

4

2 に答える 2

0

クラスTCPIPConnection、メソッドpublic ByteBuffer receive()では、次のようにする必要があります。

                    bytesRead = inputStream.read(receiveBuffer, 0, bytesToRead);
                    if (bytesRead == -1){
                        //close connection here
                    }
于 2012-03-28T06:32:14.317 に答える
0

Logica libのようなフレームワーク/ライブラリを使用することの全体的なポイントは、低レベルのAPI / TCP FINレベルの詳細からユーザーを分離することです。そうでない場合、フレームワークを使用することによる付加価値はありません。私たちはこのルートを通り抜けてきました。才能のあるTCPプログラマーがいない限り、TCPレベルで作業するこのルートは生産的ではありません。

オープンソースのSMPPlibCloudhopper（Twitterで作成され、後にオープンソース化されたもの）が非常に大規模なプラットフォームで何年にもわたって使用されているのを見てきました。これは堅牢で、多くの主要な電話会社で製造実績があります。カスタマイズに使用できるサンプルクライアントがあります。接続管理：最初にSMPP接続を確立したときに（セッションごとに）接続をキャッシュします。submitSM PDU（SMSの送信）を実行する際に、例外のタイプを確認します。これは接続例外であり、SMPPセッション/接続を再バインドして再インストールするだけです。非アクティブな期間が長い場合（たとえば40秒以上）、その端にあるSMPPサーバー/SMSCが接続を切断する可能性があります。再接続するには、次の2つのオプションがあります。a）次にsubmitSM PDUを実行するときに古い接続を検出し、再接続してキャッシュを更新してから、submitSm PDUを送信します。またはb）これが推奨されるオプションです。enquireLink pDUを定期的に（たとえば45秒ごとに）実行する別のスレッドを用意します。これにより、接続がアクティブなままになります。enquireLinkとsubmitSM PDUは、同じキャッシュされたSMPPセッション/接続を使用することを前提としています。もちろん、enquireLink PDUが接続の切断を検出した場合は、再バインドを実行して、共通のSMPPセッション/接続を更新する必要があります。私はこのアプローチが何年もの間、複数のアプリケーションでうまく機能するのを見てきました。

于 2015-07-31T11:02:05.693 に答える