• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..03-May-2022-

SMPP_Test/H01-Jun-2011-11865

ChangesH A D30-May-20112.2 KiB6954

MANIFESTH A D01-Jun-2011244 1615

META.ymlH A D01-Jun-2011292 119

Makefile.PLH A D24-Jun-2010556 148

READMEH A D24-Jun-20107.5 KiB194151

SMPP.pmH A D01-Jun-2011149.3 KiB3,5791,824

bind-hammer.plH A D03-May-20222 KiB8653

esme-hammer.plH A D03-May-20222 KiB8556

esme-rec.plH A D03-May-20227.8 KiB211178

esme.plH A D03-May-20222 KiB8352

sendmessage.plH A D03-May-20223.4 KiB13083

smsc.plH A D03-May-20228.3 KiB227190

test.plH A D03-May-202270.1 KiB2,2112,007

README

1README for Net::SMPP Perl module
2================================
312.3.2001, Sampo Kellomaki <sampo@symlabs.com>
47.7.2001,  added SMPP 4.0 support --Sampo
528.9.2001, fleshed out the readme --Sampo
629.4.2005, a small update --Sampo
721.4.2006, upgrade to 1.10 --Sampo
814.12.2008, added SMPP 5.0 support --Sampo
924.6.2010,  upgraded to support more recent perls, probably breaking 5.005 and earlier --Sampo
10$Id: README,v 1.8 2006/04/21 20:14:03 sampo Exp $
11
12This readme describes version 1.14 of the module,
13implementing SMPP 3.4, SMPP 4.0, and SMPP 5.0.
14
15Version 1.14 attempts to be compatible with perl 5.10. This may cause
16earlier perls, uch as perl 5.005 to break. If you have old perl,
17you should try version 1.13 which explicitly tried to support them
18at the cost of not supporting newer perls (why did perl have to
19change in incompatible ways). At least 1.14 has been tested on 5.8.8.
20
21WARNING: Some of the V4.0 features have been tested against real
22  world SMSC. Version 3.4 has only been tested by author against the
23  module itself. However, the author is aware of more than 20
24  production sites using the code more or less successfully on basis
25  of SMPP-3.4 protocol. I guess Net::SMPP has passed the test of
26  time and is useful in production, though, no doubt, many
27  poorly tested features remain.
28
29Version 1.03 was in use for over two years by
30multiple sites, thus I guess some stability and correctness is
31implied. Current version as of 21.4.2006 is 1.10. Given that the
32release cycles have been in multiple years, people have asked if its
33maintained at all. Yes its maintained by me, but only to fix bugs. No
34new development has been done in ages. I guess this is a stable piece
35of software so not many updates are needed. If someone wants to start
36new big project to overhaul this code base and significantly add to
37it, you are welcome.
38
39Please, if you do not know what you are doing, don't ask me to teach
40how SMPP works. If you understand SMPP, please submit bug reports and
41preferrably patches. I am also very interested in success/failure
42reports on testing different features against real world SMSCs.
43
44Introduction
45------------
46
47Net::SMPP is an implementation of Short Message Peer to Peer protocol
48over TCP. This protocol is frequently used in the telecoms and mobile
49operator world to pass short messages between systems that implement
50the short message service (SMS). It is applicable to both european GSM
51and american CDMA based systems. The SMPP protocol is documented at
52
53	www.smpp.org
54
55This module aims at fully implementing version 3.4 of the
56protocol. This module also implements 4.0 and aims to support it fully
57as well. The 4.0 code is based on documentation freely obtained from
58Logica (i.e. not under NDA). (It seems 4.0 is only in use in Japan -
59the rest of the world seems to use 3.4.)
60
61Symlabs (www.symlabs.com) uses this module in real life product
62development. Despite our commercial objectives, we have decided
63to make this module available to public in the belief that
64
65- someone else will benefit from it and thus will
66  help us debug and improve it
67- we promote better sharing of information about
68  specifications and commonly encountered usage
69  patterns (which may not always be 100% in spec)
70- open distribution protects our client's interests
71
72We are committed to keep this module under license substantially
73similar to the one under which the present release is offered and hope
74this will encourage contribution from the community. If you need other
75licensing arrangements, we as copyright holders are willing to
76accommodate you.
77
78To build an entire solution takes much more than just this protocol
79module. We are specialists in integrating various internet and telco
80protocols and building whole solutions. For integration and support
81services, please contact symlabs@symlabs.com
82
83Getting
84-------
85
86	Download from cpan.org
87
88	OR
89
90	git clone git://zxid.org/smpp
91
92Building
93--------
94
95	perl Makefile.PL
96	make
97	make test
98	make install	# su to root prior to this, if needed
99
100Testing
101-------
102
103Make test target has not been properly developed yet.
104
105Check from smsc.pl and esme.pl that you are contacting appropriate
106server, such as localhost. Launch two windows and execute following
107commands
108
109	window1: ./smsc.pl
110	window2: while ./esme.pl; do echo -n '.'; done
111
112This tests
113	- v34 bind_transmitter
114	- v34 submit_sm
115	- v34 unbind
116
117Repeat
118
119	window1: ./smsc.pl 4
120	window2: while ./esme.pl 4; do echo -n '.'; done
121
122This tests the same functionality for version 4.0
123
124Benchmark
125	window1: ./smsc.pl
126	window2: ./esme-hammer.pl
127
128	# on U1 167MHz (psrinfo -v) with both processes on the same machine
129	# I get ca. 130 synchronous submit - response pairs
130	# per second. Client seems to be slightly heavier than
131	# the server. This would seem to indicate that the encoding
132	# process is heavier than decoding (client needs to encode
133	# a big PDU and decode small one while server decodes big
134	# PDU and encodes small one). This test wa bound by CPU.
135
136	# Same test over 100Mbps ethernet seems to be bound by
137	# round trip delay (because this test uses synchronous mode)
138	# and gives 135 sync submits. Test client: U2 (2x 296MHz)
139
140	# Same test over 100Mbps ethernet seems to be bound by
141	# round trip delay (because this test uses synchronous mode)
142	# and gives 100 sync submits. Test client: U5 (270MHz), happy
143
144	# Same test over 100Mbps ethernet seems to be bound by
145	# round trip delay (because this test uses synchronous mode)
146	# and gives 105 sync submits. Test client: U5 (270MHz), joder
147
148	# Same test over net with 2 clients (running on same U2). Server
149	# is reaching CPU saturation. This gives 240 sync submits/sec.
150
151	# Same test over net with 3 clients (running on U2 & U5). Server
152	# is reaching CPU saturation (84% User, 10% kernel). This
153	# gives 250 sync submits/sec.
154
155	# Same test over net with 4 clients (running on U2 & U5). Server
156	# is reaching CPU saturation (84% User, 10% kernel). This
157	# gives 272 sync submits/sec.
158
159	# Next test: 4 client boxes (2x U5, 1x U1 with 2 cpus)
160	time perl -e '$x = 5; for (1..$x) { fork && exec "./esme-hammer.pl 3 1000" } for (1..$x) { wait; }' 2>/dev/null
161	# User 83%, kernel 14%, 259 submits / sec (20 parallel clients)
162
163	time perl -e '$x = 25; for (1..$x) { fork && exec "./esme-hammer.pl 3 1000" } for (1..$x) { wait; }' 2>/dev/null
164	# User 82%, kernel 17%, 274 submits / sec (100 parallel clients)
165
166	time perl -e '$x = 250; for (1..$x) { fork && exec "./esme-hammer.pl 3 100" } for (1..$x) { wait; }' 2>/dev/null
167	# Fairly long ramp up time can be noticed. There is idle time on server CPU so
168	# probably clients are being saturated. On server the number of processes does
169	# not seem to go over 250. maxproc limit on server?
170	# 1000 parallel clients: there start to be some weird problems and truput for
171	# some clients drops to about 80 submits/sec and as low as 22..32 submits/sec
172	# Due to many figures not fully matching expectations (e.g. number of processes
173	# on the server never reached anywhere near 1000) these results can not be taken
174	# as conclusive.
175
176	window1: ./smsc.pl
177	window2: ./bind-hammer.pl
178	# on U1 167MHz with both processes on the same machine
179	# N.B. this benchmark causes the server to fork one
180	#      process per iteration of the test. 50% of the
181	#      CPU is spent in the kernel during the test.
182	# ca. 11 bind-submit-unbinds per second
183
184License
185-------
186
187Net::SMPP is copyright (c) 2001,2010 by Sampo Kellomaki (sampo@iki.fi),
188All rights reserved. Portions copyright (c) 2001-2005 by Symlabs
189(symlabs@symlabs.com), All rights reserved.  You may use
190and distribute Net::SMPP under same terms as perl itself.
191
192NET::SMPP COMES WITH ABSOLUTELY NO WARRANTY.
193
194--Sampo