smpp latency estimation

Question

I would like to use "Wireshark" for the estimation of the average time between the submission of "sumbit_sm" smpp PDUs and the reception of the corresponding "submit_sm-resp" smpp PDUs, i.e. the average latency (round trip-delay) between "smpp" requests and responses generally.

If i am not mistaken Wireshark can display a "time since request" column but it displays the "http.time" value. Also, I cannot find a graph displaying the round-trip time (delay) for smpp traffic specifically or something related in the "statistics" menu.

So, is there any way of estimating "latency" using "Wireshark" (web or "command line" tool like "tshark", etc) ?

Answer 1

0

Well, of course you can do it for individual messages by comparing the timestamp of the request and the response. But I suppose you want to do this for many requests.

To do that without updating Wireshark's C code to include SMPP response times you'd probably have to use MATE. The biggest problem with MATE is that the documentation is woefully out of date and often inaccurate, but it would allow you to do what you want: get a field attached to SMPP response packets that lists the response time since the request.

Just to give you a start, you'd want to create a GOP (Group Of Pdus) that includes both the request and the response. MATE automatically calculates the necessary timestamps.

answered 09 Jun '15, 05:39

JeffMorriss ♦
6.2k●5●72
accept rate: 27%

Great thanks... this is something to start with...

actually i created a short script that calculates the time between (submit-sm) request and (submit-sm-resp) response.

Pdu smpp_pdu Proto smpp Transport tcp/ip {
        Extract cmd From smpp.command_id;
        Extract seq From smpp.sequence_number ;      
    Extract stream From tcp.stream;
    Extract time From tcp.time_relative;

};
Gop smpp_session On smpp_pdu Match (seq, stream) {
// Start with "smpp.command_id == 0x00000004" (submit_sm)
Start (cmd=4);
// Stop with "smpp.command_id == 0x80000004" (submit_sm-resp)
Stop (cmd=2147483652);
};
Done;

However (until now) it does not work (exactly) in the way i like.

For example (among other things): a single tcp frame may contain more than one (submit-sm) requests. It seems that the above script computes correctly the time between the request/response of one of them but it also displays the same time for the rest of those requests (as in the following screen-shot) although times should be different (e.g. in the case presented below it should something like: 0.002462, 0.003943, 0.005487, 0.006817, 0.047319 - it seems the displays the first computed time as many times as the “requests” found in this frame.

Anyway, thanks again… i will keep trying…

alt text

(10 Jun ‘15, 03:04) Aristotelis

Ok, i have revised (a bit) my script to the following version. In this way, the “latency” between request/response is being calculated correctly even in the case where there are multiple requests/responses in a single (tcp) frame. However, it should be worth mentioning that the original “tcp trace” file must be filtered based upon the “tcp stream” index, then create a new “pcap” file (containing frames of that single “tcp stream” only) and finally evaluate the “latency” making use of this “MATE” script. In this way, we will avoid a case where the same “seq-id” is being reused over different “tcp streams” (in that case this script has no “steam-index” reference and it may compute the “latency” between a request and a response “belonging” to different “tcp streams”.

Pdu smpp_pdu Proto smpp Transport mate { Extract cmd From smpp.command_id; Extract seq From smpp.sequence_number;
};

Gop smpp_session On smpp_pdu Match (seq){ // Start with “smpp.command_id == 0x00000004” (submit_sm) Start (cmd=4); // Stop with “smpp.command_id == 0x80000004” (submit_sm-resp) Stop (cmd=2147483652);
};

Done;

(10 Jun ‘15, 10:20) Aristotelis