Home AMX User Forum NetLinx Studio

ip_server_open() and URL parameters

Gday all,

I'm trying to write a server module which does different actions depending on the parameters in the URL. I've been able to open a server port, listen for connections, and serve basic replies. Where does the parameter information get stored so I can act on the parameter values?

E.g. http://my.master.com:12345/?param1=hello&param2=world

So far I am handling everything in the online event of the port. I expect that I will have to parse the parameters to get each individual value, but how do I obtain the parameters in the first place? I'm looking for a non-Duet solution if there is one, since I want it to run on my NXC-ME at home.
DEFINE_DEVICE
vdvIpPort = 0:4:0

DEFINE_CONSTANT
integer iHTTPPort = 12345
char crlf[2] = {13,10}

DEFINE_FUNCTION WaitForConnection(){
 stack_var slong theResult
 theResult = ip_server_open(vdvIpPort.port,iHTTPPort,ip_tcp)
 select{
  active(theResult == -1):{ send_string 0, 'ip_server_open() failed -1 invalid server port' }
  active(theResult == -2):{ send_string 0, 'ip_server_open() failed -2 invalid value for protocol' }
  active(theResult == -3):{ send_string 0, 'ip_server_open() failed -3 unable to open communication port' }
 }
}

DEFINE_EVENT
data_event[vdvIpPort]{
 online:{
  send_string vdvIpPort, "'Connected', crlf"
  send_string vdvIpPort, "'Parameters = '"
  //How to I access the parameters?  For debugging I'd like to send_string them back to the browser.
  //e.g. param1=hello, param2=world
  ip_server_close(vdvIpPort.port)  //Tells browser that all data has been sent
  WaitForConnection() //Reopen to listen for new connections
 }
}

data_event[vdvIpPort]{
 online:{
  wait 50
   WaitForConnection()  //Start initial listening
 }
}

Yours,
Roger McLean
Swinburne University

Comments

  • Joe HebertJoe Hebert Posts: 2,159
    annuello wrote:
    how do I obtain the parameters in the first place?
    One way is to trap them with the STRING: handler (data.text) of your IP device (vdvIpPort.)
  • Joe is correct, you have to use the STRING: { xxxx } handler in the Data Event to access the actual data. From there, I'd recommend passing off to a parsing call where you can use functions like Remove_String() to isolate the actual data in the URL.

    In my implementations, I use PHP to open the connection with the controller and send just the data, so I don't have full URLs with name/value pairs. I just connect, then send the data in a fixed format separated by periods; i.e. "zone.device.command.value<CR>". The STRING handler looks for the <CR> in the string, and when found, uses remove_string() to grab everything up to that <CR> and pass it to a parsing function.

    Using full URLS and name/value pairs allows you to get by without PHP programming to handle controller communications, and is certainly more flexible in the long run, but you're gonna have to write more parsing code to handle the URLS.

    Does the application that submits the URLS to the controller need device state feedback?
  • annuelloannuello Posts: 294
    Thanks for that. I thought I tried looking for them in the string event, but I guess I wasn't looking hard enough. Time to do some parsing.

    Yes, the app will require state feedback. Since it will be access via a web browser, I've had a quick play with some auto-refrshing HTML.
    <html>
    <head>
    <meta http-equiv="refresh" content=2>
    </head>
    
    It seems to work okay, though I'm not a huge fan of the "continuous hits" approach. If I were using a purpose-written client which keeps the connection open, I don't think I'd have such issues. If the continuous hits become a problem I may have to investigate the XMLHttpRequest object to see if that can help me out. What a good compliment to my insomnia! At leat this is all for a home-project, and not work.

    Roger McLean
  • annuello wrote: »
    ...I may have to investigate the XMLHttpRequest object to see if that can help me out.
    I think either Javascript or Flash would make a really nice, mostly-stateful interface. I'm working on that. My old-school submit forms are clunky; you need a refresh to get the current state.

    Good luck!
Sign In or Register to comment.