Porting PeerHood into Maemo environment

PeerHood has been tested in Maemo environment. Works in emulator and in the device. Battery consumption hasn't been tested, memory consumption with WLAN and Bluetooth: ~44 MB which is the same as in Linux, see analysis of memory consumption in Linux with Bluetooth only.

This is not required anymore because MakeVars file isn't used anymore in the current version of PeerHood.

“Porting” required only changing the DEPEND variable content in MakeVars from:
DEPEND=makedepend -I/usr/include/c++/4.2 -I/usr/include/linux -I/usr/include/c++/4.2/tr1

to

DEPEND=dpkg-deb -I/usr/include/c++/3.4 -I/usr/include/linux -I/usr/include/c++/3.4/tr1

because Maemo environment and N810 uses version 3.4 of C++ libraries. Also GPRS and GPRSgw -plugin directories were ignored in Makefile.- julaakko

Currently PeerHood can be built in Maemo environment without any modification. GPRS and GPRSgw -plugins need to be removed from lib-folder, if they're built (another option is to comment out them from Makefile).

Porting ideas

These are just ideas which came into mind while thinking about the usage of PeerHood in N810 internet tablet and in UMSIC project - julaakko

General ideas about porting

  • Currently the PeerHood daemon can be run as root only, it might be more usable if regular user could run it for own purposes. Or the daemon should be set to start whenever system is loaded.
  • Modify current solution in a way that it would consume less power in a mobile device
    • With current solution battery life would be drastically reduced when moving to an environment where multiple devices are present and many of them advert their own services. Actually doesn't affect too much - should be tested soon …
      • Background application shouldn't degrade the battery lifetime drastically or reserve vast amount of resources
        • Currently being tested with the device (WLAN and BT) Aborted - isn't stable enough for long term testing, although in tests after 24h run the battery hasn't drained lot
      • Continuous polling of WLAN wakes it up every time polling is executed - necessary for PeerHood to keep track of surrounding devices
        • GPS could be applied? → When coordinates change, update device list more frequently. Slow, consumes a lot of battery → reject
    • No active checking / polling of network interfaces / sockets ? Loses proactivity
      • User / application programmer could initiate searching of other devices and services
        • Starting of threads for advert / inquiry (e.g. search devices for 5 seconds)
          • Maybe threads could be set to sleep when no activity?
        • Setting some service active (INSERT_SERVICE) on a device activates advertising of that service
          • No need to advert anything if no services registered? Stop / pause thread?
        • Set background search of devices / services ? Daemon works already on the background - julaakko
    • Use only a few threads
      • Instead of multiple active threads use a event callback -based approach
        • Reactor pattern
          • As a hybrid with thread-pool approach (multiple workers ready to work - dynamic depending on work queue?) - used a lot in web-servers and has been proven that this is the most effective one. Need to find papers/reference
        • Half-sync/Half-async - modified ?
        • Acceptor-Connector pattern (apply some parts?)
        • an illustration of one idea - glib causes overhead?
        • Test with debugger shows that currently every thread takes roughly 8 MB of memory (not in use, reserved virtual memory).
    • Do not start plugins with daemon ? Plugins need to be loaded but not started, on the other hand they could be started and set to sleep when there is no need for that particular plugin or part of that plugin - julaakko
      • Listeners for this - monitor device/system state!
  • no threads for adverting / inquiring / listening ? Threadless version would require probably too much change in the structure - not applicable
    • In some situations there could be a need to advert something (own service, acting as centralized server in adhoc network?)
  • Use PH daemon, but use it only to monitor events?
    • I/O callbacks with GLib-functionality?
    • Asynchronous approach? If an operation lasts long → slows the system (waiting times)
    • Solution (?) → Start plugin threads only when something has happened (event) and a certain plugin has to deal with the occurred event and stop itself (idle or completely quit) when event has been dealt with. Thread could inform daemon via D-BUS or emitting a signal (if possible?) when the event has been dealt with. Or this could be seen from thread status (currently implemented, more usable → no extra needed)

PeerHood research subject

  • One possibility is to implement only some parts of PeerHood into UMSIC-project if it cannot be modified to be resource-friendly in N810.
    • e.g. take parts of code that it still is compatible with other PeerHood enabled devices but the internal functionality could be transformed into a more light-weight form.
    • Need to investigate which solution would reduce the battery and resource usage of PeerHood daemon
      • Centralized version: all sockets monitored in single thread and pluginthreads are awaken only when there is need for them
        • Reactor and threadpool -hybrid. Efficient.
      • Centralized version 2: all sockets monitored in single thread and pluginthreads are created only when there is need and destroyed when there is no need.
        • Might reduce performance..
      • Current version: threaded - advert, inquiry and listen threads for every plugin and each of them listen sockets/handles belonging to them
      • Reactor version, using GLib as reactor, which invokes certain threads or sends signals when something needs to be done.

Optimize memory usage (solved)

  • Linux implementation (PHD alone) takes ~21 MB memory (~19 virtual) with bluetooth only. With WLAN plugins memory consumption goes over 40 MB
  • Plugin threads not always active - might reduce memory usage a lot Virtual memory reserved when thread is started, see test
  • use profiling to see which parts take vast amounts of memory - optimize variable usage Tests done, see page containing test results.
    • started threads This consumes memory a lot - reserves a large block, see test
    • loaded plugins? Consumes memory only a little, see: test.
    • unnecessary statically loaded variables? Although in Maemo environment static variables should be preferred, memory usage could possibly be reduced with dynamic memory allocation in continuous usage Tests do not indicate that this is a problem..
    • unnecessarily large strings / char arrays? Tests indicate that this isn't the issue
    • libraries? Tests indicate that the libraries do not consume vast amounts of memory

Device Monitoring

  • Could it be possible to implement a method for monitor latencies of connections?
    • Could be used in UMSIC project to monitor the quality of link(s) when acting as a “jam session” server in adhoc mode. Voice and instrument sound synchronization could be quite hard if the latencies between devices rise into too high levels → if sound is out of sync it would be hard to play together (think of playing a guitar with a drummer who cannot keep up steady tempo)
  • Monitor only specific devices (friend devices)
    • Identification via MAC / bluetooth address ?
    • certificates (Maemo env. has certificate system for applications to use)

PeerHood and D-BUS

  • PH daemon should listen to system D-BUS messages (battery low, shutdown, offline mode )
    • Implemented with listeners and listener “framework” for initializing and using listeners for different purposes → Can be correctly shut down and stop all activity
    • Add support for using D-BUS (all applications in Maemo should register to D-BUS - otherwise application is killed - affects only user applications started from menu). Use D-BUS via LibOSSO or directly via libdbus (?).
    • Use D-BUS for other activities? (vs. local socket)
      • service registration / removal? - Would require a implementation of a handler that deals with reply-messages
      • Activation of service?
      • Use PHD objects via D-BUS (define interfaces with xml and register to D-BUS) - bad?
        • using plugins “directly” (?)
Not suitable, because D-BUS is not as reliable as local socket → would require a implementation of sending/receiving replies for messages. Would change current functionality too much. - julaakko
  • Could the D-BUS be used for instance PeerHood daemon initiation / startup ?
    • Could the objects in daemon be used via D-BUS?
      • provide object interfaces to D-BUS with xml-definitions?
    • Invoking daemon when running PeerHood library notices an event (using callback in mainloop) via D-BUS?
Not suitable, would require too much changes, bad idea.. - julaakko

Bluetooth

  • Modify Bluetooth plugin → use BlueZ library
    • Currently using lower level functionality (L2CAP - or is it?) - already uses BlueZ
    • Always running? Bluetooth consumes power only a little
      • For example in UMSIC project external instruments could (should) be actively monitored when connected (instruments would connect via bluetooth)
    • Limitations of Bluetooth:
      • Maximum amount of active slaves in the same piconet: 7 (3bit address)
        • Bandwidth is shared by all active members in the same piconet
        • Passive (parked) slaves in the same piconet: 256
        • Scatternet?
      • Bluetooth has no broadcast-address → cannot send data for all
      • Bluetooth has no multicast-address → multiple unicasts → delay and increase in latency
    • A feature in Bluetooth:
      • In Linux using the BlueZ-library some adapters start to report errors after running for several hours. See bluetooth feature testing
  • Localization of information / debug messages?
    • General localization / Maemo specific localization ?
  • Modify PeerHood daemon that it doesn't require root-access in Maemo env. (nokia N810)
    • Should be run as service → root access (?)
  • Alter variables into Glib-types - A thing in future perhaps..
    • enhances portability
    • a lot easier to bind to another languages
    • disadvantages compared to standard libraries?
    • Maemo environment uses Glib → already loaded into memory

Limitations of Maemo environment conserning PeerHood Linux-implementation

  • A bit limited processing capabilities compared to modern PCs
    • TI OMAP 2420, 400 Mhz
      • ARM1136 processor running at 330 MHz
        • In ARM11 processors the cost of context switches is greatly reduced compared to ARM9 processors (saving amounted to a 37-67% reduction in cycles)1)
  • Limited amount of system memory
    • 128 MB DDR RAM
    • 256 MB Flash
  • Battery lifetime
    • 1500 mAh battery
    • Operating time up to 4 hours with continuous usage (screen on, WLAN active)
  • Memory should be allocated and freed in large blocks
    • Prefer static variables
  • “No busy looping in maemo”

FIXME