Hi, I agree. Returning (1) doesn't mean that it has sent partial data, just that it uses buffered output and it waits for it to fill before it sends it. That is no guarantee that the message will be sent correctly (maybe bearerbox is restarted), but it is better than assuming that it was never sent.
BR, Nikos ----- Original Message ----- From: Raf Coremans To: [email protected] Sent: Thursday, April 02, 2009 8:02 PM Subject: unlocked_try_write returning 1: OK or not OK 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
