meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

peerhood:problem [2010/03/22 12:00]
julaakko
peerhood:problem [2011/09/02 12:05]
Line 1: Line 1:
- 
-====== Problems in PeerHood ======= 
-PeerHood **problem** list page. Describe here problems (one or two paragraphs) in [[start|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. 
- 
- 
- 
-==== Lack of test cases ==== 
-[[project#​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. 
- 
-- [[wiki:​user:​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:<​code>​FetchPrototypes:​ Found new proto �p^SA�p^SA^P for xx:​xx:​xx:​xx:​xx:​xx</​code>​or<​code>​FetchPrototypes:​ Found new proto �p^SA�Y?​ for xx:​xx:​xx:​xx:​xx:​xx</​code>​ 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? 
- 
-- [[wiki:​user:​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. 
- 
- 
-[[wiki:​user:​hevi]] 
- 
- 
-==== Service hijack! ==== 
- 
-Currently a service can be hijacked on a device, meaning that if a service with same name is registered it will get new port number different from the one given to the "​older"​ service but when a client tries to connect to this service the connections are going only to the "​newer"​ service. The "​older"​ service is still operational but no connections are forwarded to it since the "​newer"​ one with same name is found before that.  
- 
-==== Service re-registration on Bluetooth ==== 
- 
-Connections via Bluetooth to a service will fail if there was a service with the same name which was closed before but then re-registered. This means that PeerHood daemon was continuously running and NOT restarted during the stopping and re-registration of a service. If some other device tries to connect to this service using Bluetooth the connection can not be created. 
- 
-This needs more testing, since problem was noticed when PeerHood daemons were running on all devices in the neighborhood for the whole period of operation. It is required to test if this affects new devices which arriving to the vicinity (which know nothing about the connected devices). 
- 
-==== Service count bug ==== 
- 
-This is a very rare bug but will cause some devices with small memory capacity to crash. At some point the daemon reports that is has received 25717 or 25701 services from another daemon which means that after this the daemon is creating a list for these services, the size is equal to received amount of services and usually the daemon crashes after this.  
- 
-The service amount is sent as a short (16bit) integer. Need to figure out whether this bug is in receiver or sender. 
- 
-==== Socket and handle usage is faulty ==== 
- 
-After ~48h of operation there exists over 1000 open handles owned by peerhoodd. Need to check every socket and handle usage (opening & closing!)