最初の 、最も問題のある欠陥：切断時のmessage_idの損失。 彼らはこの送信操作（submit_smなど）に苦しみますが、そのために答えが届きませんでした。 このプロトコルには、失われた識別子に対する組み込みの回復ツールは含まれていません。 その結果、メッセージのステータスが来ると、添付するものは何もありません。 さらに、このSMSCメッセージが受信されたかどうかは不明です。
交換が同期モードで実行される場合、1つのメッセージのみが失われます。 しかし、作業が非同期モードで行われると、損失が大きくなる可能性があります。
SMPPのこの欠点は、おそらく思い出せない唯一の解決できないプロトコルツールです。 もちろん、問題は標準化されていない方法で解決されます。
残りの欠点は、実装の問題に関連しています。 彼らの解決策は、原則として、SMSCとSMPPクライアントの間で合意に達することであり、仕様を超えない。
2番目の欠点は、私を大いに困らせますが、配信レポートdeliver_smに関連しています。 プロトコルバージョン3.4は、ステータス情報の送信方法を厳密に定義していません。 一方では、message_stateおよび関連するパラメーターが厳密に型指定された形式で渡されるオプションのTLV構造があります。 SMSCがこの構造内の長いコメントを送信できないことを除いて、このオプションは適切です。 ただし、このメソッドが必須（MUST）と示されている場所はありません。 ただし、プロトコルの付録に例を示します。 私は強調します：例。 推奨すらありません。 SMSCがどのようにステータス情報を報告するかの例（ああ、なんてことだ！）short_messageフィールド。 つまり テキスト形式、奇妙な略語、ワイルドフォーマットなど。
一般的に、これは可能なオプション（MAY）の1つを選択する状況です。 プロトコルの実装に関する私の意見では、プロトコルで許可されているオプションの1つを選択することは、パケットを作成する当事者の特権です。 この場合、レポートパッケージはSMSCです。 そして、受信側は、プロトコルに一致するパケットを正しく処理する義務があります。 しかし、厳しい現実は、支払う人は正しいと言っています。 SMPPクライアントの大部分は、short_messageフィールドのみを理解します。
この仕様は、プロトコル（アプリケーション）の5番目のバージョンの仕様から削除されましたが、5番目のバージョンのSMPPクライアントを見つけてください。
3番目の欠点は、長いメッセージの送信です。 仕様は、標準[GSM 03.40]ショートメッセージサービスポイントツーポイントの技術的実現を控えめに参照しています。 目立たないので、特に見ているときにのみリンクに気付くことができます。 この標準への参照は、バージョン3.4の仕様のセクション1.4参照に記載されています。
質問：short_messageフィールドは、GSM 03.40に従ってのみプロトコルで使用されることになっていますか？ GSM 03.40は、UDHヘッダーを備えた一連の連結されたsmsに分割された長いメッセージテキストを提供します。 SMPP仕様は、暗黙的に自由な使用を推奨しています-254オクテットのフィールド長。 これらはラテン語の2つのsmsまたはキリル文字のほぼ4つのsmsです。
SMPP仕様を注意深く読みました。
4.4.1「SUBMIT_SM」の構文
「...最大254オクテットのショートメッセージユーザーデータ。 「short_messageサイズの正確な物理的制限は、基盤となるネットワークによって異なる場合があります...」
つまり 基礎となるネットワークによって制限が課せられます。 このケースでは、基盤となるネットワークはGSM 03.40によって記述されています。 したがって、140バイトのデータ。 なぜそんなに長いフィールドなのか？ 実際には、7ビットエンコーディングを使用でき、文字はすでに160です。short_messageは、バイト単位のバイナリではなく、オクテット単位のテキストフィールドです。 おそらく、クリエーターは他のより洗練されたオプションを決めました。
明らかな理由により、SMPPクライアントの開発者は、タスクを簡素化したいと考えています。 そして、その側では、連結されたSMSと通信しようとしません。 SMSCプロトコルに従って、選択した形式（標準化されていない）で、message_payloadフィールド（メッセージをSMSに独立して分割し、ヘッダーを提供）を介してこのようなサービスを提供できます。 しかし、プロトコルは必要ありません。 はい。通常のテキストメッセージにのみ、これを恐れることなく適用できます。 ビジネスの観点から見ると、質問も滑りやすい-そのようなメッセージをどのように評価するのか？ しかし、すべてのメッセージ部分がステータスを配信していない場合はどうでしょうか？
4番目の欠点は、相対時間形式に関連しています。 指定された時間を測定するものに関連して？ クライアントまたはSMSCのいずれにも遅延がなく、それらの間に良好なコミュニケーションがある場合、通常、質問は発生しません。 しかし、どこかで遅延がある場合、クライアントとSMSCの参照ポイントは大幅に異なります。
schedule_delivery_timeについては、セクション5.2.15で以下を指定します。
「..このメッセージの配信がSMSCによって試行される現在のSMSC時間からの相対時間..」
しかし、これは異なる参照点の問題を解決しません。
文学
- ショートメッセージピアツーピアプロトコル仕様v3.4
- [GSM 03.40]ショートメッセージサービスポイントツーポイントの技術的実現»