Track pdu/pdu_resp with external ids

[archseer]

Hi! In our usecase, we construct a pdu, we store it in the db, and we send it off (submit_sm). Once we get a submit_sm_resp, we want to update the db to set it's state to "sent" and store the message_id returned in submit_sm_resp. While handle_resp(pdu, original_pdu, st) gives us the pdu + original_pdu, it's impossible to tell what pdu in the database it is, since we can't tag the pdu with the database id (and the Refs returned by make_ref() can't be properly serialized into DB).

What would be the best way to do that? I've considered tagging the pdus with an optional field TLV, ":internal_id", so that it'd stay on the original pdu, but that would be extra bytes getting sent off (as well as leak our internal ids to the other side). Another option I've considered is forking the code and modifying the PduStorage to instead store a "seq_number -> uuid" pair, then handle_resp would return the uuid as the second variable instead of the original_pdu, however that doesn't seem too attractive as I'd need to maintain a fork...

[archseer]

Also, using the ESME.Sync implementation is not an option for us, since blocking would decrease perf

[savonarola]

Hello!

The SMPP protocol does not provide a reliable way of obtaining some "message id" before a response is received. The messages and resps are associated through sequence ids, which are often duplicate for different SMPP sessions.

So the only way (which is followed by SMPPEX) to keep some sort of "global identity" is to make a ref to be part of Pdu's.

One of the probable solutions (which we generally use) is the following:

• We instantiate a simple key-value store (for example, an ets table), keeping correspondence pdu ref <=> pdu db id
• When we need to send a message, we:
  • Generate a PDU
  • Insert it into DB in some "not sent" status and obtain its db id
  • Associate pdu ref and pdu db id in our store
  • Send PDU
• Then, in handle_pdu_sent callback we obtain pdu db id by pdu ref from our store and update PDU status to "sent" in the DB
• Then, in handle_resp callback we again obtain pdu db id by pdu ref from the store and update PDU status to "sent and got resp" in the DB, optionally updating obtained message_id.

[archseer]

Hi @savonarola, thanks for the reply! I ended up implementing a system just like that and it works great :) thank you for providing this library by the way, it's proven to be very efficient so far (especially the UDH/multipart handling)!