This two-part post will look at two protocols, HTTP and CoAP, for providing REST services for constrained environments. The REST architectural style was developed by W3C Technical Architecture Group (TAG) in parallel with HTTP/1.1, based on the existing design of HTTP/1.0. The World Wide Web represents the largest implementation of a system conforming to the REST architectural style.
REST-style architectures conventionally consist of clients and servers. Clients initiate requests to servers; servers process requests and return appropriate responses. Requests and responses are built around the transfer of representations of resources. A resource can be essentially any coherent and meaningful concept that may be addressed. A representation of a resource is typically a document that captures the current or intended state of a resource.
A wireless sensor node may use a REST service to send sensor observation data to a data logger or to request configuration updates from a server.
We begin by looking at the evolution of HTTP. All HTTP versions are plain-text based protocols, i.e. no compression is performed and only printable characters are used.
HTTP version 0.9, still supported by modern web servers including the Apache HTTP server, has a simple request protocol which consists of opening a TCP connection and sending a plain-text string in the form of
GETfollowed by a carriage return and a line feed. Headers are not supported for requests and only the
GETmethod is available. There are also no headers attached to a response and so a zero-length response would simply result in the connection being closed. Parameters such as a sensor ID and sensor reading can be attached to the URL as parameters in order to be processed by the server.
HTTP version 1.0, again still supported by modern web servers including the Apache HTTP server, has a more complex request protocol. Once the TCP stream is opened a plain text string in the form of
METHOD /url HTTP/1.0followed by a carriage return and line feed must be sent. The version number added to the request informs the server that the newer version of the protocol is in use. As HTTP/1.0 supports headers, a second carriage return and line feed must be present to indicate the end of the headers section. There are no required headers for HTTP/1.0.
HTTP version 1.1, the currently most widely deployed version of HTTP, adds further complexity by requiring the presence of a "Host" header in all requests. HTTP versions 1.0 and 1.1 also support the
POSTmethod, where the parameters are passed as a request body, which requires the additional "Content-Type" and "Content-Length" headers.
The minimum request size, assuming an 8 character sensor ID, a 5 character sensor value, an 11 character hostname and the update script being at the root of the server, for each protocol is shown in the table below:
POSTrequests for HTTP versions 0.9, 1.0 and 1.1
One of the stated uses for the
POSTmethod within the HTTP/1.0 specification is ``extending a database through an append operation" which is exactly what submitting a sensor result should do.
GETrequests are meant only for retrieving information, whether from static resources or from data generating processes.
GETrequests should not be used for performing any updates or changes. As a result, with version 1.0 and 1.1 of the HTTP specifications the use of a
GETrequest to submit sensor readings would break the intentions for use laid out in the specification.
Zero-length responses from the server with versions 1.0 and 1.1 would in fact have the server respond with an HTTP status code of "204 No Content", a number of headers, and a human-readable message as an HTML document explaining the status code. This size of this would be likely to be significantly larger than the request, although the page returned in this case by the server is configurable. As the connection is already using TCP, there is nothing gained from the reciept of a response from the server by the sensor node.
Following this analysis of the HTTP versions, it seems that as the HTTP protocol evolves, more and more complexity is being added that all adds up to increase the amount of bytes that need to be carried over the constrained low-power low-bitrate networks that wireless sensor platforms use.
The SPDY/2 and SPDY/3 protocols, whilst in current use, have not been considered for the same reason that HTTP over SSL and HTTP over TLS have not been considered. The overhead of the encryption and key generation would place considerable load on the processing power of constrained environments. Encryption, if necessary, should be implemented at the MAC layer where it can be performed by hardware as opposed to software with less overhead and reduced power consumption.
In part two of this post, the new Constrained Access Protocol (CoAP) will be introduced and analysed for its fitness for purpose in constrained environments such as wireless sensor nodes.
Post a Comment