Re: HTTP Module
"Alejandro Guerrieri" <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
René, I've just started implementing somewhat similar to your third approach before reading your mail. What I'm starting to do is 1. Receive the SMS on a dispatcher process (PHP). 2. The dispatcher "injects" the message on Kannel using a special HTTP module I've developed for the same aggregator (yes, on another short number they have an asynchronous interface! Don't ask...). That module allows me to pass a "ticket" on the "binfo" field. I use this to track messages from and to kannel. 3. The dispatcher module keeps waiting for the queue to populate with the ticket-indexed message. This I'll do it with periodically with a SELECT query. 4. I've configured the HTTP module to POST the MT's to another "response" process (PHP). 5. The response process uses the ticket to populate the MySQL queue with the app response. 6. The dispatcher then detects the newly added entry, get it, print it with the proper formatting and terminate the process. I think it will work (I've made a proof of concept using regular files instead of a MySQL table and it works ok!). Now I'm polishing some details, mostly error handling and queueing, but I think it will work like a charm. I'll post my findings on the list, just in case anyone else have a similar problem. Thank's for your help. -- Alejandro Guerrieri Magicom http://www.magicom-bcn.net/ LinkedIn: http://www.linkedin.com/in/aguerrieri On 4/1/06, Rene Kluwen <[email protected]> wrote: > Hello Alejandro, > > Starting with your last comment: Yes, doing this from PHP would be a much > simpler approach. > There's several ways within Kannel that can do the job. > > One is to use an sms-service that sends the proper reply. You need some > threading glue in between the receive_sms() & send_sms() function to > coordinate everything. But it can be done. > > Another is to queue all incoming messages in the send_sms() function. > You just add them to a gw_list. > Whenever an HTTP GET request comes in, you extract the message from the list > and pass it on in the reply body. > > A third option is to put every incoming message into a MySQL table. And use > PHP to do the actual GET request/response thingies. > This way you can put the protocol logic in PHP whilst yet retaining Kannel's > routing options. > > These are just three examples that I can come up with in a few mintues. > Probably there will be a lot more ways to do it. > > Cheers, > > Rene Kluwen > Chimit > > -----Original Message----- > From: [email protected] [mailto:[email protected]]On > Behalf Of Alejandro Guerrieri > Sent: zaterdag 1 april 2006 17:26 > To: [email protected] > Subject: HTTP Module > > > Dear List, > > I've developed a couple of HTTP modules in the past, to accomodate to > third partie's particular requirements. Most of them are propietary > (their specs are particular to us) but we are talking with a couple of > them about releasing the module so other people can connect to them > using kannel. > > Since most HTTP apis are asynchronous (one connection to us when a > message arrives and we establish a connection when we want to send a > message)wWe usually start from the "kannel" http module, change the > parameters and a few other things and we are done. > > They work fine and we didn't experience any particular issues with them. > > But now, a third party is asking us to use a "synchronous" connection. > > I mean: The third party connect to us using an HTTP GET and we should > respond on the reply to _that_ request with a line of text containing > the message we want to send. Then their system sends the message to > the originating number. > > I know it's an _horrible_ approach: > > It has no queuing, retrying, validation nor failure detection. > We can only respond to messages originating from them. > We cannot know if there were any issues with the sending (since I > don't get a "Sent" response from them). > > Anyway, it's what they've got and what they are asking to use, so our > hands are tied there. > > The problem is _how_ to implement this in an HTTP module. Since kannel > uses an asynchronous approach, I don't know where to start. > > AFAIK, when a message is injected from the HTTP interface, it arrives > at "kannel_receive_sms" and the message is put on the incoming queue > using "bb_smscconn_receive": > > ret = bb_smscconn_receive(conn, msg); > if (ret == -1) > retmsg = octstr_create("Not accepted"); > else > retmsg = octstr_create("Sent."); > } > > And then the HTTP interface replies wit "Sent" or "Not accepted": > > reply_headers = gwlist_create(); > http_header_add(reply_headers, "Content-Type", "text/plain"); > debug("smsc.http.kannel", 0, "HTTP[%s]: Sending reply", > octstr_get_cstr(conn->id)); > http_send_reply(client, HTTP_ACCEPTED, reply_headers, retmsg); > > At the end, cleanup is performed: > octstr_destroy(retmsg); > http_destroy_headers(reply_headers); > > Later on, the message is picked on the smsbox, processed and the > response is processed on a separate thread. > > The problem is, I'd need to respond _inmediately_ with the response on > the same HTTP connection. In other words, instead of "Sent" I'd need > to respond with the message I'd want to send. > > Is that possible? What would be the best approach to do that? AFAIK it > would need to keep the HTTP connection open and waiting for the smsbox > to respond, but how could I do that? > > I know I can do this easily from PHP or any scripting language, but > using kannel I can keep my routings (we have a _lot_ of them) on a > single place. Using PHP "glue" would mean we have to replicate all our > "sms-service" group logic outside kannel and I want to avoid that if I > can, since we many different regex-keywords on many short numbers > pointing to many apps and mantaining those settings on two different > places would be an daministrative nightmare. > > Any hints about this would be appreciated. > > Best regards, > > -- > Alejandro Guerrieri > Magicom > http://www.magicom-bcn.net/ > LinkedIn: http://www.linkedin.com/in/aguerrieri > > > >