meta data for this page
This is an old revision of the document!
Problems in PeerHood
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
Too many open files
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
Lack of error management
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.
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
Generally all possible exceptions should be catched.
Mobile network is inherently “faulty”, no ideal network. More fault management into code.
When daemon receives a
SIGINT signal it doesn't close:
- Connections to local clients
- Listening thread of Wlan plugin. Inquiry and advert threads are stopped but the
WLANPlugin::UnListenis never called.
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
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?