System Introspection for System Analysis on Mobile Devices

More documents

Recommendations

Info

elements available <strong>for</strong> logging cycles.After parsing the configuration the XMPPCommunicator is created. This establishesthe communication with the details of the ServerConfig. On successfulconnect to the communication server, all component threads are created andstarted by using the list of component threads from the ServerConfig class.Each component thread gets a reference to the communicator, a reference tothe component holder and is added to the observers of the list of all connectedclients. Initialized component threads are stored inside a map <strong>for</strong> further processing.When all component threads are initialized, the MainDispatcher,ComponentDispatcher and the LogDispatcher are created. By using thedifferent dispatchers the communication flow between the corresponding subelements and the client can be controlled. Elements can only be requestedby calling these dispatcher classes. Each dispatcher gets a reference to thelist of connected clients and observes the communicator. For sending messagesa reference to the communicator is passed. The LogDispatcher and theComponentDispatcher need some additional references. The LogDispatchergets a reference to the component holder and the server configuration. Thereference to the ComponentHolder is <strong>for</strong>warded on request to each createdLoggingCycle. The ServerConfig is used to create a list of available loggingcomponents. The ComponentDispatcher gets the map of all initializedcomponents <strong>for</strong> controlling the communication between clients and componentthreads.MainDispatcherThe MainDispatcher class handles all the communication with the clients. Toreceive commands and send messages the MainDispatcher holds a referenceto the Communicator. The MainDispatcher observes the communicationinterface <strong>for</strong> new commands send by clients. All possible commands are definedas constants in the Constants class and represented as enumerations.The MainDispatcher controls the list of all connected clients by using theClients class referenced on creation. Whenever a client sends a connect command,the MainController adds the new client to this list or removes theclient on receiving a disconnect command. To monitor the connection to aconnected clients, the MainDispatcher is running a loop process checking thelist of connected clients and exchanging a beacon with each client (see chapter5.1). Inside the loop the MainDispatcher checks the beacon count <strong>for</strong> everyconnected client. If the beacon count is below a count <strong>for</strong> maximum missingbeacons, a new beacon message is created and <strong>for</strong>warded to that client. If thecount equals a maximum count the client is removed from the list. Removinga client from the list triggers a notify on all listeners. This principle allows to37
stop all active processes of the corresponding client. The frequency of the loopand the count of maximum missing beacons are defined in the XML configurationfile. To receive incoming beacons the MainDispatcher also observesthe Communicator. When a new beacon is received the beacon count <strong>for</strong> thecorresponding client reseted to zero.ComponentDispatcherThe ComponentDispatcher class controls the communication between componentthreads and clients and observes the Communicator <strong>for</strong> new requestsfrom clients. The available commands are stored inside a Constants class.To control the different component threads the ComponentDispatcher holdsa list of all available component threads and their current state. On requestthe list is <strong>for</strong>warded to the to clients. When a client requests the data of acomponent thread, the ComponentDispatcher checks the current state of thecomponent thread. If the state is RUNNING, the client is added to the clientlist of the component thread. If the state is SLEEPING, the client is added tothe client list and a notify() event is executed to activate the componentthread. Whenever a client requests a disconnect from a component thread,the dispatcher removes the client from the list of the corresponding componentthreads.ComponentThread - Live ObservationFor the implementation of a component thread a ComponentThreadInterfaceand a ComponentThread base class where created. The idea of the base classis to capsule the methods <strong>for</strong> receiving and sending messages and only offersimpler functionality <strong>for</strong> the extending classes. For receiving messages thebase class observes the Communicator. New messages are handled inside theupdate() method by reading messages from the Communicator. The elementsof the messages are parsed and stored in the receivedProperties map <strong>for</strong>further processing. Due to the need of executing multiple component threadsin parallel the ComponentThread extends the Thread class.The base class holds several lists. The connectedClients list contains allclients currently connected to this component thread and is used to <strong>for</strong>warddata to those clients. Whenever the list is empty the component thread is getsdeactivated. The globalClients list is a reference to the list of all clientsconnected to the probe. Observation of this list allows to remove clients fromthe connectedClients list whenever a client disconnects from the probe. ThereceivedProperties list holds all properties extracted from a new message38
Page 1: Bringing System <s
Page 5 and 6: AbstractSystem <st
Page 7 and 8: output, so each component is offeri
Page 9 and 10: of the system and the decisions mad
Page 11 and 12: created a telelaboratory where two
Page 13 and 14: Like the telelaboratory there is a
Page 15 and 16: with a very high frequency which ma
Page 17 and 18: Due to improving technology the use
Page 19 and 20: Figure 4.1: ToBI platfor</s
Page 21 and 22: Figure 4.3: The architecture behind
Page 23 and 24: Figure 4.5: Typical instant messagi
Page 25 and 26: 5 System DesignThe
Page 27 and 28: Figure 5.2: Message exchange betwee
Page 29 and 30: Figure 5.4: Beacon running between
Page 31 and 32: Figure 5.5: Reading and processing
Page 33 and 34: data and only forw
Page 35 and 36: For example a developer can select
Page 37 and 38: Figure 5.13: Principle of tabbed na
Page 39 and 40: 6.1 The Communication InterfaceThe
Page 41: 6.2 The Probe - Implementation of t
Page 45 and 46: is received containing the TAG of t
Page 47 and 48: The selected sensors give a good im
Page 49 and 50: 1 2 4 6 8 Listing 6.2: Example of t
Page 51 and 52: TabConfig - The Status ViewThe TabC
Page 53 and 54: Each view adds a listener to the co
Page 55 and 56: LoginController which also observes
Page 57 and 58: tends the JPanel class. The templat
Page 59 and 60: 7 EvaluationIn the previous chapter
Page 61 and 62: Name Description CharactersSingleli
Page 63 and 64: Figure 7.1: Latency of receiving da
Page 65 and 66: For this thesis only a rough estima
Page 67 and 68: Laptop CPU load without Probe CPU l
Page 69 and 70: 8 ConclusionsIn the context of this
Page 71 and 72: 9 OutlookGiven this new tool its no
Page 74: BibliographyBurrell, A. and A. Soda
Page 77 and 78: 6.10 Main classes of the Java clien
Page 79 and 80: AppendixUse CasesUse Case 1: Connec
Page 81 and 82: Use Case 4: Disconnect from compone
Page 83 and 84: Use Case 9: Sending beacon to keep
Page 85 and 86: Figure 9.4: Latency of receiving da

System Introspection for System Analysis on Mobile Devices

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?