dissertation

Author: nenuadrian

.DS_Store

@@ -0,0 +1,52 @@
+\section{Conclusions}
+\subsection{Limitations}
+There was only so much the agent can do based on the requirement of having a low footprint. A cap on CPU and memory usage has not been implemented but would be necessary. 
+
+\subsection{Testing}
+Having multiple components, cross-operating system specifics and a bit of a learning curve required on the side of testers made the overall implementation harder to test and required more time to identify and rectify issues.
+
+\subsection{Room for improvement}
+
+\subsubsection{Multiple instances of the same app}
+A mechanism could be setup to handle multiple recurrences of the same stack-traces so that they are not recorded multiple times (such as computing an unique hash based on the contents of the trace).
+
+Agents could communicate to each other on the local network and share information about captured exception so as to avoid unnecessary processing being done.
+
+\subsubsection{Code overlay - in progress}
+For maximum efficacy, the dashboard should be able to display the code of every method on the stack-trace with an overlay of variable values on it.
+
+There are multiple concerns with this approach which is why the implementation of this feature has been halted to make room for other critical parts.
+
+How would the code-base be obtained? The agent has some code to handle directory parsing and looking into .Jar files. Research has been done into disassembling .class files and native libraries which could accomplish this. However, the complexity of an automated system which could handle this process was considered beyond the current scope of the project.
+
+Also, once obtained, the code-base must be kept in an encrypted format and decrypted inside the user browser potentially using the same key which could be used for encrypting the variable data.
+
+\subsubsection{Resource capping}
+Limits should be imposed on the size of the heap that is to be recorded.
+
+\subsubsection{Ignoring framework-specific code}
+
+Stack-traces will most of the time very likely include methods which are not of interest, such as the ones of the framework we might be using (Spring, etc).
+
+\subsubsection{Data Compression - in progress}
+
+Miniz \cite{miniz} is a loss-less and quick data compression library coded in a single source file. This brings a low footprint on the agent library and reduces the bandwidth usage and increases speed at which data would be transferred from the agent to the API and between agent instances.
+
+It is compiled as part of the agent code-base but full implementation was not achieved.
+
+\subsubsection{Encryption}
+AES256 encryption was supposed to be used to encrypt the variable date inside the agent before sending it to the storage system via the API. The key would have been stored locally and generated by the user.
+
+The openssl library was meant to serve the native agent side of cryption \cite{openssl}.
+
+The dashboard's Javascript library would have then used the same local key to decrypt the data once it safely arrived from the storage system, through the API, into the user's local browser and hence memory. This library was supposed to be used on the client side \cite{cryptojs} which supports AES cryption.
+
+In this manner, the captured data would be readable only to key-holders.
+
+\subsection{Concluding remarks}
+The core of an utility for debugging JVMs in the described way was designed and built as a result of this project.
+
+The tool has a built by developers for developers style, rendering it quite technical. This made it harder to test but brought more benefits to specialised end-users.
+
+The JNI and JVMTI are powerful means to explore and manipulate the behaviour of JVMs and provide the means to develop advanced tools for both debugging and improving performance, this project being one of the many tools which could be developed using them.
+\newpage