Repository navigation
Known issues and behaviors
FragMe now runs on JGroups3. JGroups3 has been modified to run on android. It runs on android 4.1 but it is likely that it will not run on versions of android below this.
An application may make a change to an FMeObject which does not change it's contents. For example, a FMeObject subclass contains a field "temperature". The application updates this variable from "13" to "13". It may then call change() on the object, which causes the object to be sent to it's peers. If the receivers wish to detect these "boring" updates and ignore them then the developer should implement the following:
- In their FMeObject subclass, add a transient boolean field "hasChanged" (or any other appropriate name can be used).
- In deserialize(FMeObject), set hasChanged to false. Before setting the subclass variables from the incoming object, check for changes. If any field has changed then set hasChanged to true.
- In changedObject(), if !hasChanged then return, otherwise process the change as usual.
This method could be used in some other interesting situations:
- Suppose an FMeObject subclass contains a field which should be propagated but which does not need to trigger changedObject(). For example, it contains temperature data and a timestamp of when the termperature was collected. We might want to trigger changedObject() when the termperature changes, but not each time the timestamp changes.
- Suppose an FMeObject subclass contains a field which should only trigger changedObject() when a significant change is detected. For example, only trigger changedObject() when total rainfall passes each increment of 10mm.
Of course, it may be possible for the sender to detect that the change they want to make to an object is irrelevant and to skip calling change(), making these checks unnecessary. Note that this may or may not have problems when receiving new objects, depending on your application - they may or may not trigger changedObject(). Ensure they do by adding another variable "isNew" = true to your subclass, then, during deserialize, is if is true then set it to false and hasChanged to true. Or initialize some variable in your subclass to an impossible value.
When an FMeObject is changed by a peer which is not the owner, the change is sent only to the owner. The change is received by the FMeObject's owner, who then owner transmits the update to all their peers, including the peer that made the change. This means that the peer that made the change will receive a changedObject() notification. FragMe could be modified (in ObjectManagerImpl.java:receiveChange(...)) to prevent sending to the original changer, but there would be a large overhead cost to do this. Instead, the developer can prevent these changes from having any meaningful effect on their application by using the method described for detecting and processing updates which do not change the content of a FMeObject.
This issue has been resolved:
If two peers start at the same time then they will create separate groups with the same name. Future peers joining the simulation will join to one of the peers. They all seem to join the same group, leaving one of the initial peers alone (but I can't guarantee that this is always the case). This all seems to be caused by JGroups behavior (but I'm not guaranteeing that). I'm not sure which they choose to join, but I am guessing that it is related to port numbers (perhaps always the peer with the lowest port number).
The following was thought to be a problem, until it was realized that changes to an unowned object are first sent to the owner, who then retransmits the changes:
It is possible to receive an update for an object which hasn't yet been initiated. This is currently being observed during start up (need to test after start up). This is most likely caused by the following situation:
- Peers p1 and p2 exchange data d1 and d2.
- Peer p3 joins and initiates setup with p1 and p2.
- Peer p1 and p3 complete their setup and exchange data (d1 and d3) before p2 completes setup with p3.
- Peer p1 makes a change to d2 and sends the update to p3.
- Peer p3 receives the update to d2 but it has not yet initialized the object (belonging to p2) so it produces an error.