Re: [Nolug] Introducing myself - SMPP client

Actually the Android development and SMPP are completely different
things in my world.

I need SMPP, and sometimes few other protocols in order to establish a
connection between my gateway and a wireless carrier for SMS messaging.
I currently have about 30 connections already. they have been
established using an SMPP client in windows. While the client app still
works relatively fine, I can already see some problems arising from
windows updates, which potentially break programs made with 10yr old tools.

Our current SMPP app core can utilize many other protocols such as SEMA,
UCP, CIMD, HTTP, XML, SOAP, etc. all potentially used with SMS
messaging. Our client can operate as client or server. It is speedy
enough, since fastest traffic I've observed so far was only about 15 msg
/sec. Biggest slowdown is due to waiting an ack from SMSC. (Short
message Center at operator end), then if you add up to 10 connections to
one client, and traffic is fast in all of them, the app has a tendency
of crashing every now and then and so far we have not found a reason to
it. The program appears to be running normally, but it is not doing so
internally. Biggest culprit so far has been some windows' own web api,
our smpp pclient is utilizing. And that is the one we can not fix. That
is also the biggest reason I want dump windows. Most problems are due to
windows stuff.... There may be similar problems in Linux world as well,
but I still feel more comfortable with Linux.

Did you guys know, windows file system corrupts itself after 300K
files...... I found that out after generating and transferring 1
Million files via our internal message router ("wicked fast" perl
program ...err.. script). Luckily the server was not in production at
the time......

Petri

PS. I had indeed incorrect version numbers for SMPP protocol in my
previous post.

Dennis J Harrison Jr wrote:
> I have only played with smpp very little recently (zenoss). I
> remember from a few months ago someone on twisted list talking about
> trying to implement a better smpp for python lib. There is really
> nothing out of the box iirc. Alvin (forgot his last name) is the
> resident expert in that field. And he chimed in with what looked like
> a decent bit of info on what it would take to get twisted doing what
> it sounds like you want to do.
>
> Ahh, I found the post I was talking about.
>
> http://www.twistedmatrix.com/pipermail/twisted-python/2007-December/016475.html
>
> lol... few months ago. Sheesh. Time flies.
>
> However. There seems to be a standard smpp implementation on android
> already. Have you looked at it yet?
>
> says support for 3.3 and 3.4 with 5.0 in the works (Project doesn't
> seem very active however).
>
> Take a look at this stuff and see if you can build on it. Or if you
> need to do something different.
>
> Aside from the included smpp implementation in android:
> http://code.google.com/p/jsmpp/
>
>
> You should hop on the android dev group and ask. Aside from talking
> smpp... What are you trying to do?
>
> are you looking for some transaction management in relation to ???
>
>
>
> On Sun, Dec 7, 2008 at 8:39 AM, Petri Laihonen <pietu@weblizards.net> wrote:
>
>> Ron Johnson wrote:
>>
>>> On 12/06/08 22:43, Petri Laihonen wrote:
>>> [snip]
>>>
>>>> Another reason was that the programs need to be able to multithread and
>>>> be wicked fast.....
>>>>
>>> Threaded programming can be really hazardous, because:
>>>
>>> a) in Windows (and sometimes in Unix) they all run in the same address
>>> space, and an errant pointer in thread A can stomp on something in
>>> thread B, and
>>>
>>> b) you need to be very careful to avoid race conditions.
>>>
>> There is a remote possibility that I may have misunderstood the meaning
>> of multithreading, but the one below is one of the main functions of an
>> SMPP client.
>> - The ability to establish 2-way communications via socket.
>> - There are 2 modes, BTX/BTR (uses 2 sockets, one receives the other one
>> transmits, however both do acks, thus in real life must be somewhat
>> 2-way. BTRX handles both directions via one socket.
>> - Amount of connections via one client program is normally one to two,
>> but could be n. (so far highest we had has been 10 BTX/BTR connections)
>> - Communications are most often synchronous, however more and more, the
>> SMSCs we would connect to, can be capable of asynchronous transactions,
>> thus needed as well to increase efficiency.
>> - naturally also all the activity according to SMPP 4.2, 4.3, and 5.0
>> standards.
>> - Some additional goodies for manipulating the messages. (Currently we
>> have our own scripting language for in and out traffic.)
>>
>>
>> Therefore, does the above require multithreading or not?
>> Any suggestions of what programming language would be the most suitable one?
>>
>> Petri
>> ___________________
>> Nolug mailing list
>> nolug@nolug.org
>>
>>
> ___________________
> Nolug mailing list
> nolug@nolug.org
>
>
___________________
Nolug mailing list
nolug@nolug.org
Received on 12/07/08