At 11:39 AM 8/14/02 +0200, Stipe Tolj wrote:
>You don't get submit_sm PDUs from the SMPP server, do you?! I guess
>you mean deliver_sm PDU for MO messages?
nope, submit_sm_resp, one of our providers can lag behind up to 500 odd
messages..
>Ok, you want to splitt the send/receiving threads fr
> -Original Message-
> From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
>
> > I don't agree here - I personally don't like threads all
> that much: they have their purposes, but using a new thread
> whenever you need a new context is not a good choise,
> especially if both threads need to
> I don't agree here - I personally don't like threads all that much: they have their
>purposes, but using a new thread whenever you need a new context is not a good
>choise, especially if both threads need to do IO on the same socket : major problems.
>we just need better logic handling the "s
> What happens when there are a largish number of messages in the
> msgs_to_send list,
> 1. the send_messages loop runs and we end up with a situation where one
> needs to throttle the throughput to the SMPP server
> 2. the send_message loop now sleeps
why is there a throttling in the loop? I don
> -Original Message-
> From: Nisan Bloch [mailto:[EMAIL PROTECTED]]
>
> Hi All
>
> We are experiencing the following problem with the SMPP module.
>
> 3. the io_thread doing send_messages now cannot call
> send_enquire_link
> regularly enough to check whether it is time to send an
>
Hi All
We are experiencing the following problem with the SMPP module.
There are 2 instances of io_thread
sender: - calls send_enquire_link and send_messages
receiver: - calls send_enquire_link, after each PDU it reads and handles.
What happens when there are a largish number of messages in the