meta data for this page
  •  

This is an old revision of the document!

Problems in PeerHood

PeerHood problem list page. Describe here problems (one or two paragraphs) in PeerHood. For more problem text link to other page. When solution is found move problem description to the solution page.

Bluetooth operation

Should we use DBUS (commands, adapters)for Bluetooth operation (discovery) http://wiki.bluez.org/wiki/Adapter

Consuption of the power in network availability monitoring ?

Using wireless network consumes power. PeerHood pro-active functionality in regular manner polls networks this increasing device power consuption.

Lack of specification document

What are specific peerhood requirements ?

Is PeerHood ready for 24/7 operation ?

Robustness of code ? Error handling, gives segfault in multiple places, simply due lank of returned null pointer management. Thread safety ?

Suggestion: every one network connections in comlab should go through PeerHood.

Slight problems with Bluetooth

Briefly: after PeerHood daemon (alone, no services or applications using the daemon) has been running for ~7 hours or more it either crashes (segfault or in latest tests assertion error in CBTConnection line 40) or starts reporting -1 responses from surrounding bluetooth devices and also errors reported by BTPlugin::Inquirythread : 

Too many open files

and 

Device or resource busy

First could be result from hci_inquiry -function functionality, second could be from thread safety issue in BlueZ bluetooth library. For further information, see: a possible feature found in Bluetooth library/hardware functionality - incl. testing.

Lack of test cases

Testing

Lack of error management

Errors

Specification or documentation of returned types from functions. Error condition specifications are often ignored.

Handling of error, null result or non default path returns from functions. NULL for a usable object is returned but not handled ⇒ obvious sigsegv.

Exceptions

It would be good to implement exception catching - throwing into PeerHood. When PeerHood daemon is being run on N810 Internet tablet it occasionally terminates itself when new operator throws std::bad_alloc.

Generally all possible exceptions should be catched.

Faults

Mobile network is inherently “faulty”, no ideal network. More fault management into code.

Closing signals

When daemon receives a SIGTERM or SIGINT signal it doesn't close:

  • Connections to local clients
  • Listening thread of Wlan plugin. Inquiry and advert threads are stopped but the WLANPlugin::UnListen is never called.

- julaakko

Generally implementing shutdown functionality to daemons.

FetchPrototypes in BTPlugin

When PeerHood is used in the N810 Internet tablet, FetchPrototypes -function in BTPlugin reports irregularly something odd: 

FetchPrototypes: Found new proto �p^SA�p^SA^P for xx:xx:xx:xx:xx:xx

or 

FetchPrototypes: Found new proto �p^SA�Y? for xx:xx:xx:xx:xx:xx

where xx:xx:xx:xx:xx:xx is another PeerHood capable device (PC), same device in all situations.

A character conversion error? Failure in send or receive?

- julaakko

PeerHood testablity

On mobile (PAN) network devices apprear and disappear in to the user device. How to build this kind of environment into single development computer ?

There should also exists multiple instances of peerhoodd in single device.

hevi