Re: unlocked_try_write returning 1: OK or not OK

Hi Ralf,

you are absolutely right. I wonder me why we never spotted this issue  
early...
Anyway it's fixed now in cvs. Please try it.

Thanks,
Alex

Am 02.04.2009 um 19:02 schrieb Raf Coremans:

> Hi list,
>
>
> A few days ago, I asked the user list about a "wrong sequence  
> number" error that I randomly get using SMPP (http://www.mail-archive.com/[email protected]/msg15479.html 
> ). I have now investigated this further and I have it tracked down  
> to the way that send_messages() interacts with unlocked_try_write().
>
> On the one hand:
> send_messages() only considers a return code of 0 to be an OK return  
> code for send_pdu() [line 1011 of smsc_smpp.c in version 1.4.3].
> This return code of send_pdu() comes, via conn_write(), from  
> unlocked_try_write().
>
> On the other hand:
> unlocked_try_write() has three possible return codes: "Return 0 for  
> success, 1 if there is still data left in the buffer, and -1 for  
> errors." [lines 280-281 of conn.c in version 1.4.3].
> So, according to the comment, -1 is definitely an error. But is 1  
> also to be considered as an error (which is what send_messages()  
> does)? Is it really an error if the buffer is not yet completely  
> flushed?
>
> We've noticed that when bearerbox sends PDUs in quick succession, we  
> sometimes get unlocked_try_write() returning 1. On the SMSC side  
> (using the sctt SMSC simulator), we see that the PDU arrives  
> correctly. But since send_messages() considers this 1 as an error,  
> it does not register the sequence number, so bearerbox doesn't  
> recognize the submit_sm_resp, and later resubmits the message.
>
> => Any thoughts? Should send_messages() be made less strict, and  
> consider send_pdu() >= 0 as OK, rather than send_pdu() == 0?
>
>
> Regards,
> Raf