• No results found

The research in this thesis can be continued in two ways: extensions to or con- tinuations of the research presented in this thesis or application of the methods and approaches used in this research to new problems or problem domains.

There is one immediate extension to the work in this thesis; the current im- plementation of protothreads does not implement the full protothreads model because of the limitations of the C preprocessor. By implementing a special pre-compiler that would translate protothread-based code into regular C code it is possible to implement the full model. This also makes it possible to mini- mize the memory overhead of protothreads.

The work on energy-efficient loading of program modules can be continued in at least two ways. Firstly, the energy consumption for transferring loadable modules in Contiki can be reduced by compressing the modules with loss-less compression techniques before the modules are transmitted across the network. Investigating the use of standard compression techniques and the trade-offs in terms of computational energy consumption is an interesting continuation of the work on the dynamic loader in Contiki. Secondly, it would be interesting to compare the use of dynamic module loading in Contiki with differential-based mechanisms for loading modules in monolithic operating system. Investigating the trade-offs and how they vary with different applications and network types would be interesting.

Finally, the approaches and methods used in this thesis can be applied to nearby problem areas. The memory management scheme used in uIP, where a single buffer is used for both incoming and outgoing packets, might be possible

5.2 Future Work 29

to apply to other types of network protocols, such as power cycling MAC pro- tocols for sensor networks. By using a single buffer, rather than a multi-buffer management scheme, it might be possible to reduce both the data memory re- quirements and the code footprint. However, additional mechanisms might be needed to ensure that no packet queuing is required.

The research in this thesis suggests that there is a relation between imple- mentation complexity in terms of memory footprint and the achievable appli- cation performance; the smaller uIP implementation achieves much lower net- work throughput than the larger lwIP implementation. A system designer that requires high throughput can choose the larger lwIP stack, whereas a system designer that requires a low memory footprint, but does not have any through- put requirements, can choose the smaller uIP stack. It would be interesting to investigate if this relation exists in other types of protocols as well. For exam- ple, many protocols for distributing software updates through sensor networks have been developed [30, 33, 45, 55, 64], each having different properties in terms of both performance and footprint. A system designer would want to be able to choose how much system resources to commit to the software update feature and what kind of performance to expect from the feature, depending on the requirements of particular deployments. By implementing a set of software dissemination protocols and measuring their memory footprint and achievable throughput it might be possible to quantify trade-offs between memory foot- print and performance.

The systems in this thesis are built using a “bottom-up” approach rather than a “top-down” approach. Instead of breaking down the system into smaller components that are independently implemented and composed into a com- plete system, I have started from the bottom with a set of simple building blocks from which I have built a system that is similar to, but not always equivalent to, a system built from the top down. It would be interesting to use this approach for building new programming mechanisms such as abstractions for programming of aggregates of memory-constrained networked embedded systems, so-called macro-programming. Other approaches towards building macro-programming systems have started by defining the programming inter- face and decomposed this into smaller modules that are executed by each indi- vidual node, e.g. the work by Newton et al. [56, 57] and Gummadi et al. [24]. By instead building upwards from a set of small and simple node-level abstrac- tions to an abstract interface for network-level programming it may be possible to build macro-programming systems that are more efficient in terms of both implementation complexity and network communication than systems built in a top-down fashion.

Chapter 6

Other Software and

Publications

6.1

Software

In addition to the software I have developed as part of this thesis I have written a number of other programs that are relevant to the research in this thesis.

Miniweb A proof-of-concept implementation of selected parts of the TCP/IP protocol stack together with a simple web server. The code con- sists of 400 lines of C and uses only 30 bytes of RAM. Although the implementation sacrifices a large number of protocol mechanisms, it does include TCP’s congestion control mechanisms. The code is not intended for actual use. The source code is available at http://www.sics.se/˜adam/miniweb/.

phpstack A proof-of-concept implementation of an application-specific TCP/IP stack together with a web server written in 600 lines of PHP code. The TCP/IP stack is more simplified than the Miniweb stack and can only participate in single-segment sessions. Thus pages served by the web server are limited to 1460 bytes. If the program had been imple- mented in a low-level language such as C, it would only have required a handful bytes of RAM. The code is not intended for actual use. The source code is available at http://www.sics.se/˜adam/phpstack/.

32 Chapter 6. Other Software and Publications

VNC client, SMTP client, HTTP client, IRC client, and web browser

Proof-of-concept implementations of a number of application-layer protocols built on top of uIP and Contiki. The purpose was to investigate if the event-driven interface of uIP was expressive enough to implement complex application layer protocols. However, it turned out that many of the protocols required complex state machines on top of the event-driven interface of uIP. This insight lead me to develop protothreads. The source code is available at http://www.sics.se/contiki/.