Hi Alex, This seemed to do the trick. unlocked_try_write() sometimes still returns 1, but this no longer leads to a "wrong sequence number" error. Disclaimer: I only applied your changes in send_pdu(). I didn't check out the whole cvs repository because we did some customization in the source code. Thanks, Raf (not Ralf ;))
________________________________ From: Alexander Malysh [mailto:[email protected]] On Behalf Of Alexander Malysh Sent: Thursday, April 02, 2009 22:32 To: Raf Coremans Cc: [email protected] Devel Subject: 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
