meta data for this page


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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
peerhood:problem [2010/03/22 11:13]
peerhood:problem [2011/09/02 12:05] (current)
Line 21: Line 21:
 Suggestion: every one network connections in comlab should go through PeerHood. 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''​ : <​code>​Too many open files</​code>​ and 
-<​code>​Device or resource busy</​code>​ 
-First could be result from ''​hci_inquiry''​ -function functionality,​ second could be from thread safety issue in BlueZ bluetooth library. For further information,​ see: [[peerhood:​peerhood_bluetooth_feature_and_testing|a possible feature found in Bluetooth library/​hardware functionality - incl. testing]]. 
 ==== Lack of test cases ==== ==== Lack of test cases ====
Line 77: Line 73:
 [[wiki:​user:​hevi]] [[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!)