| Name : perl-Net-SMPP
| |
| Version : 1.19
| Vendor : obs://build_opensuse_org/devel:languages:perl
|
| Release : lp154.6.1
| Date : 2023-01-27 17:36:35
|
| Group : Development/Libraries/Perl
| Source RPM : perl-Net-SMPP-1.19-lp154.6.1.src.rpm
|
| Size : 0.19 MB
| |
| Packager : https://www_suse_com/
| |
| Summary : Pure Perl implementation of SMPP 3.4 over TCP
|
Description :
Implements Short Message Peer to Peer protocol, which is frequently used to
pass short messages between mobile operators implementing short message
service (SMS). This is applicable to both european GSM and american
CDMA/TDMA systems.
This documentation is not intended to be complete reference to SMPP
protocol - use the SMPP specification documents (see references section) to
obtain exact operation and parameter names and their meaning. You may also
need to obtain site specific documentation about the remote end and any
protocol extensions that it supports or demands before you start a project.
This document follows the convention of spelling parameter names exactly as
they appear in the SMPP v3.4 documentation. SMPP v4.0 support also follows
the respective documentation, except where v4.0 usage is in conflict with
v3.4 usage, in which case the latter prevails (in practise I believe no
such conflicts remain in the madule at present). For a complete list of
error code and optional parameter enumerations, the reader is encouraged to
consult the source code or SMPP speciofications.
Despite its name, SMPP protocol defines a client (ESME) and a server (often
called SMSC in the mobile operator world). Client usually initiates the TCP
connection and does _bind_ to log in. After binding, a series of request
response pairs, called PDUs (protocol data units) is exchanged. Request can
be initiated by either end (hence \"peer-to-peer\"?) and the other end
reponds. Requests are numbered with a sequence number and each response has
corresponding sequence number. This allows several requests to be pending
at the same time. Conceptually this is similar to IMAP or LDAP message IDs.
Usually the $smpp object maintains the sequence numbers by itself and the
programmer need not concern himself with their exact values, but should a
need to override them arise, the seq argument can be supplied to any
request or response method.
Normally this module operates in synchronous mode, meaning that a method
that sends a request will also block until it gets the corresponding
response. Internal command used for waiting for response is
$resp_pdu = $smpp->wait_pdu($cmd_id, $seq);
If, while waiting for a particular response, other PDUs are received they
are either handled by handlers (set up by constructor) or discarded. Both
command code and sequence number must match. Typically a handler for
enquire command is set up while all other commands are silently dropped.
This practise may not be very suitable for transceiver mode of operation
and certainly is not suitable for implementing a SMSC.
Synchronous operation makes it impossible to interleave SMPP operations,
thus it should be regarded as a simplified programming model for simple
tasks. Anyone requiring more advanced control has to use the asynchronous
mode and take up the burden of understanding and implementing more of the
message flow logic in his own application.
In synchronous mode request PDU methods return a Net::SMPP::PDU object
representing the response, if all went well protocolwise, or undef if there
was a protocol level error. If undef was returned, the reason for the
failure can be extracted from ${*$smpp}{smpperror} and
${*$smpp}{smpperrorcode} (actual codes are undocumented at the moment, but
are guaranteed not to change) variables and the global variable $!. These
variables are meaningless if anything else than undef was returned. The
response itself may be an error response if there was an application level
error in the remote end. In this case the application level error can be
determined from $pdu->{status} field. Some responses also have optional
parameters that further clarify the failure, see documentation for each
operation.
If a protocol level error happens, probably the only safe action is to
destroy the connection object (e.g. undef $smpp). If an application level
error happens, then depending on how the remote end has been implemented it
may be possible to continue operation.
Module can also be used asynchronously by specifying async=>1 to the
constructor. In this mode command methods return immediately with the
sequence number of the PDU and user should poll for any responses using
$pdu = $smpp->wait_pdu($cmd_id, $seq);
Typically wait_pdu() is used to wait for a response, but if wait_pdu() is
used to wait for a command, the caller should generate appropriate
response.
If caller wants to receive next available PDU, he can call
$pdu = $smpp->read_pdu();
which will block until a PDU is received from the stream. The caller would
then have to check if the PDU is a response or a request and take
appropriate action. The smsc.pl example program supplied with this
distribution demonstrates a possible framework for handling both requests
and responses.
If the caller does not want to block on wait_pdu() or read_pdu(), he must
use select() to determine if the socket is readable (*** what if SSL layer
gets inserted?). Even if the socket selects for reading, there may not be
enough data to complete the PDU, so the call may still block. Currently
there is no reliable mechanism for avoiding this. If this bothers you, you
may consider allocating a separate process for each connection so that
blocking does not matter, or you may set up some sort of timeout (see
perlipc(1) man page) or you may rewrite this module and contribute patches.
Response methods always return the sequence number, irrespective of
synchronous or asynchronous mode, or undef if an error happened.
|
RPM found in directory: /packages/linux-pbone/ftp5.gwdg.de/pub/opensuse/repositories/devel:/languages:/perl:/CPAN-N/15.4/noarch |
