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.

Lack of test cases

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

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!)