What are the details for encapsulating M2MXML for HTTP transport?
I can understand where a client M2MXML endpoint might send Percepts as HTTP POST requests to a server, and the server would respond with HTTP 200 OK messages to confirm. But what about Commands coming down from the server? Does HTTP support any type of unsolicited messages the server?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I have been doing is scheduling GET requests to the server on intervals to see if there are any commands waiting. If there is another method for unsolicited messages, I also would like to know.
Bill
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Sent M2MXML command to the device via SMS (of course limited to 160 characters)
- Have either a UDP or TCP Socket listener and receive M2MXML commands asynchronously to process.
- At the end of each M2MXML readings sent to the server, or periodically, send a poll request of the form UUID=nnnn where nnnn is a unique identifier for the device. The server responds with a HTTP 200 and either a blank body (no commands) or the M2MXML in the body of the response.
-- Rod Montrose
AVIDwireless
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On further investigation, it appears this problem has been addressed by the web community who refer to it as "Reverse AJAX". One's options appear to be:
1) Polling. Client polls the server periodically with a brief or empty request to allow it to respond with a command. (What Bill and Rod said)
2) Comet. The client issues a special parallel request that the server responds to veerrry slloowwly in order to prop the connection open indefinitely.
3) Piggyback. The server waits on the client application to issue an unrelated request, and then tacks on a command with the response.
Each has their drawbacks, but option #1 seems the simplest. Of course another option not available to web servers would be to simply have both a client and a server running at each end, but issues with NAT probably rule this out as a useful approach for M2M.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We recently add the "Piggyback" support so any response message, if it has M2MXML in it will be processed. I didn't think of breaking it out separately as a mechanism.
I hadn't been aware of "Comet" support. Interesting idea, though it would require a separate thread to wait to process the request.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What are the details for encapsulating M2MXML for HTTP transport?
I can understand where a client M2MXML endpoint might send Percepts as HTTP POST requests to a server, and the server would respond with HTTP 200 OK messages to confirm. But what about Commands coming down from the server? Does HTTP support any type of unsolicited messages the server?
Thanks
What I have been doing is scheduling GET requests to the server on intervals to see if there are any commands waiting. If there is another method for unsolicited messages, I also would like to know.
Bill
Here is what we have done in our AVIDdirector:
- Sent M2MXML command to the device via SMS (of course limited to 160 characters)
- Have either a UDP or TCP Socket listener and receive M2MXML commands asynchronously to process.
- At the end of each M2MXML readings sent to the server, or periodically, send a poll request of the form UUID=nnnn where nnnn is a unique identifier for the device. The server responds with a HTTP 200 and either a blank body (no commands) or the M2MXML in the body of the response.
-- Rod Montrose
AVIDwireless
On further investigation, it appears this problem has been addressed by the web community who refer to it as "Reverse AJAX". One's options appear to be:
1) Polling. Client polls the server periodically with a brief or empty request to allow it to respond with a command. (What Bill and Rod said)
2) Comet. The client issues a special parallel request that the server responds to veerrry slloowwly in order to prop the connection open indefinitely.
3) Piggyback. The server waits on the client application to issue an unrelated request, and then tacks on a command with the response.
Each has their drawbacks, but option #1 seems the simplest. Of course another option not available to web servers would be to simply have both a client and a server running at each end, but issues with NAT probably rule this out as a useful approach for M2M.
We recently add the "Piggyback" support so any response message, if it has M2MXML in it will be processed. I didn't think of breaking it out separately as a mechanism.
I hadn't been aware of "Comet" support. Interesting idea, though it would require a separate thread to wait to process the request.