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
Received on 12/07/08
This archive was generated by hypermail 2.2.0 : 12/19/08 EST