| SMPP Server questions |  Search
|
|
NowSMS Support Forums ⬆ NowSMS Support - MMS & Advanced Issues ⬆ Archive through April 05, 2007 ⬆ |
◄ ► |
| Author | Message | |||
| Stéphan Kochen New member Username: Stéphan Post Number: 3 Registered: 11-2006 |
Hello again, I'm looking into handling delivery receipts. But the situation is rather special. I have to send a message and check if it arrived at the destination in a single function from within another application. I cannot return from this function and come back later; I have to block in this situation. Implementing this is difficult with the HTTP interface. I could launch a dummy process or implement a tiny HTTP server that NowSMS can send it's notification to. But either way, I have to set up a second communication channel. Therefor, I was looking at the SMPP interface instead, hoping NowSMS would send me the receipt back on the same connection. I have a couple of questions, though: a) Does NowSMS send back delivery receipts to the connection that sent them? Can it handle multiple connections properly? (I haven't been able to test this, because: ) b) It looks like there is a bug in the SMPP server: I send a "bind_transceiver" message, and the "bind_transceiver_resp" message I get back reports a length of 16, which is only the header. According to the standard a required parameter "system_id" should follow. I tried sending a "submit_sm" or "enquire_link" message after this, ignoring the missing parameter before. Both times the response was a packet containing 16 NULL bytes. Could this be the "system_id" parameter being sent in a separate packet, but not reported in the header's length field? Or am I missing something here? c) Is there a better way to do this, perhaps using the HTTP interface after all? (I already have code successfully talking to NowSMS over HTTP, just not handling delivery receipts.) Thanks in advance, -- Stéphan | |||
| Bryce Norwood - NowSMS Support Board Administrator Username: Bryce Post Number: 6835 Registered: 10-2002 |
Hi Stéphan, a.) It sends the delivery receipt back to the same user account that submitted the message. If you have multiple client connections from the same user account, the receipt could go to any of those clients. b.) I'd need to see a debug log (SMPPDEBUG.LOG), otherwise I'm just guessing. The bind response always includes "NowSMS" as the system_id. My guess would be that the bind is being rejected ... as that would be a 16 byte response. c.) SMPP seems like a good quick and dirty solution. You just have to deal with the issue of how many outstanding requests do you allow at one time, because you will need to have a separate "SMS Users" account defined for each concurrently outstanding request (to ensure that the receipt comes back in on the same user account). Of course you could use HTTP to dynamically provision user account as you need them, but that seems messy. To do it with HTTP ... basically your application would just need to block waiting on an external trigger. The delivery receipt would get routed back to a 2-way command, which would be another HTTP script ... and within that script, you would perform the trigger to unblock the wait in the other process. This trigger might be a database update, where the blocked process/thread is polling waiting for a database update, or it could be more sophisticated depending upon what environment you are working in and what facilities are available for interprocess communication and synchronisation. -bn | |||
