## 6 Results
### Workload  
Comprehensive benchmarking requires a study of the effects that high workloads have on a server. In this study, we evaluate the percentage of requests that a server can handle as a function of the request rate of the client. We refer to the percentage of the handled requests with the term server rate. The test setup considers a client sending GET requests at a fixed rate. For each rate we run 100 tests. The resulting server rate is the average percentage of requests at which the server replies correctly in each test. The payload of the server response is greater enough to fill an IEEE 802.15.4 frame. In this test, we evaluate only unreliable solutions. The presence of retransmissions does not allow maintaining constant the client rate. A client using CoAP reliability is forced to stop sending requests and start retransmitting. The server therefore would not be subjected to a constant workload. As a consequence, we use CoAP NON messages. The only reliability mechanism in use is that of the MAC layer. We do not consider the use of HTTP/TCP. At present, the implementation of TCP does not allow accepting more than one connection at time. As a consequence, the rate with which a client sends requests is extremely limited. The average latency for HTTP/TCP considering a response sent in a full 802.15.4 frame is equal to 302 ms. Therefore, the maximum rate a client can have is estimated to 3 requests per second. We consider this rate too low for being compared with other solutions. Also the HTTP persistent has not been taken into account. In this solution, the rate at which a client sends requests cannot be controlled. It is the TCP congestion control algorithm that manages this rate. Figure 9 shows the average success rate of each considered solution. Figure 9: Number of requests handled by the server as a function of the client rate. The enhanced buffers of TinyCoAP allows to that to overcome the CoapBlip performance. The server rate performance is affected by the buffer size of the nodes and the mechanism used to access to the channel. A request or response could find the sending buffer full and, therefore, it would be discarded. This is more likely to happen when a client generates requests at a rate greater than that at which it can send them. Besides the processing time, the propagation time and the CSMA-CA mechanism are the main limitations of this rate. The propagation time account for the time needed to send the requests and to receive the MAC acknowledgment. A client has to wait for the server to acknowledge the receipt of the frame before sending another. In this work we use the unslotted CSMA-CA [2] of the IEEE 802.15.4 standard. This defines the procedure that the MAC and PHY layers have to follow for sending a packet. The node waits for a random number of backoff slots, then it perform the clear channel assessments (CCA). Should the client find the channel idle during the CCA period, it sends the request and then switches from the transmitting to receiving mode in a time that is called turnaround. Therefore, if the packet generation time were lower than that taken for the CSMA-CA plus the propagation time, then the client would fill its buffer faster than it can empty it. According to [48] this time is estimated to 6.09 ms. This is comparable to the packet generation time relative to a client rate of 150 requests per second. This time, however, is only an estimation. We expect that collisions are frequent in a congested wireless link. These imply MAC retransmissions and, consequently, a growth of the time needed for completing a request/response transaction. Packet collisions are also the main cause of the server rate degradation. These could happen when a node senses the channel idle during the turnaround time of its pair. Therefore, a request and a response could collide. This phenomenon is more likely to occur when the client rate is high. Furthermore, the channel becomes quickly congested and therefore the probability that a node senses it busy is high.