Computer Networks, Security and Operating Systems: Lunar Lander Controller

Software Architecture

My controller is built to run constantly on two threads, I use one thread for receiving user inputs and the other to update the user dashboard. I then have 2 other threads which are created whenever needed, one is used to send and receive Lunar Lander server messages and the other is used to log inputs and the status of the lander to the data log file.

The decision to have the user input and dashboard update on threads of their own came as this allows both to run concurrently, without having to wait through the others delays, for example the dashboard update method does not have to wait for a user input in order to send the update message. I think this is a good implementation of both methods as they are simple, easy to understand and function well. Both threads are created after the server address is checked for errors and the data log file is emptied.

The get input thread uses begins with a while loop, which lasts until the program is terminated. The while loop scans for user input then a switch statement decides what should be done with the input. If the input is a control for the lunar lander a new thread is started in order to send the server command required. Before the thread is created a semaphore checks that the thread is not already in use, if it is the command has to wait until the thread is ready. This thread then sends the command, receives the response and then joins the thread back to the get input thread. Next a thread is started to log the users input to the data log file. Again the program uses a semaphore to first check if the logging thread is in use, if it isn’t the operation proceeds.

The logging thread first prints the passed parameter from the function which states the control which was pressed, for example throttle up. Next the function requests the state and terrain from the server, as it always does the server request uses its own thread, checking if anything is using that thread and waiting for it to finish. The condition is also logged, however since the dashboard retrieves that every 0.1s I stored that in a variable and use the most recent  condition in order to place slightly less stress on the server. This information is all appended onto the end of the data log file.

The dashboard runs on its own thread which was created at the same time as the get input thread, again it runs a while loop until the program is stopped. The while loop checks if the server thread is in use, using a semaphore, then requests the condition from the lunar lander server. Next it sends the condition to the dashboard, updating it. Finally the I use the usleep command to delay the next loop from occuring for 0.1s.

I decided to handle user input using scanf as is it a built in method that works, however I considered using the ncurses library to detect if the key is held down. I decided against it incase the assignment did not allow different packages. This meant that each input requires an enter press afterwards and because I used a switch statement each control input had to be a single character. I found, however, that this worked very well for gameplay and was easy to adjust to.

Dashboard Communication

The protocol I chose to implement, for handling the dashboard communication was very simple. I figured out that from C I could pass on the returned condition string to the dashboard, with minimal changes. The only change I make to the string is to replace any “%” symbols with an empty space. This allows the Java program to understand the string without any modification, and works without any problems.

I did not add any error checking to make sure that the information had been transmitted accurately, which might be a problem when transmitting via UDP, but only when over sending the messages over far distances. I ultimately decided that it was unnecessary as the messages are sent so rapidly that an error would be hardly noticeable. However, had I decided to do it I would have included a checksum check, in order to verify that the message was transmitted accurately.

Data Logging

I decided to log the state, condition, and terrain information every time the player controls the lander. I decided all of this information was important as no single factor lead to the lander crashing, it was all of them. I decided to log on every key press as the specification declared that the data log should record the user input. It also worked out very well for file sizes as it limited the amount of writes to a number small enough to never take up too much space. I chose to log my data in a “.txt” file as it means that the user can easily open it and review their data.

OS Theory and Concepts

Hardware Abstraction Layer 

The hardware abstraction layer is a layer of programming, between the hardware and the software of a computer, that enables an operating system to communicate with a hardware device (Rouse, 2005). The operating system’s job is to make the hardware easy and simple to use for high level (application) programmers, it does this by providing an abstract view of the hardware that is standardised so that programs can interact with any version of the same type of hardware can be understood without requiring a specific implementation.

An example of this is that most PC operating systems, such as Linux, provide a driver for SATA port drives. This driver allows the computer to utilise hardware connected to its SATA ports, without needing to understand the fundamental workings of each specific type of SATA drive as discussed in a lecture by (Kendall, 2019). This enables the file system to be viewed in high level systems such as windows explorer easily. The hardware abstraction layer can be accessed either via the operating system’s kernel or from a device specific driver that is sometimes used by a piece of hardware such as expensive computer mice or printers. In either case, the program’s interactions with the hardware device are more general and simpler than they would otherwise be (Rouse, 2005).

Another example is gamepad controllers, there are many types of controller that work on windows PCs. The hardware abstraction layer is used to take inputs from these controllers, standardise the data sent from the joysticks and buttons. This allows programmers to capture the inputs, from many types of controller, in a single format, making their development process clean and simple as explained by (Eizikovich, 2016).

Resource Manager

Resource management is another key function of a computer’s operating system.  It is required to systematically allocate access to the many components of a computer, such as the processor, memory, network interfaces. The efficiency of the resource manager is very important to the speed and functionality of a computer, as the correct prioritisation of tasks keeps a computer running efficiently. The operating system needs to allocate resources so that the any processes running simultaneously do not interfere with each other (Kendall, 2019).

As discussed by (Tanenbaum and Bos, 2014) there are two types of resource management mechanisms; time multiplexing and space multiplexing. When a resource is time multiplexed, processes queue to use it one at a time. An example of this is in the CPU, only one process can be active on each core at any time. This means that the resource manager has to limit all of the active tasks’ access to the CPU. Determining which process should go next is the task of the operating system, different tasks have different priorities and a good resource manager will make sure that the high priority tasks get access to the processor as quickly as possible while making sure low priority tasks still get an opportunity to progress. Space multiplexing instead shares the resources, allowing each process to access part of the resource it needs. A good example of this is memory, which is divided up amongst all of the active processes by the resource manager, normally a process is allowed as much memory as required, but if more memory is demanded than is available in the system it is allocated to higher priority tasks, and tasks that are low priority are left with less than they requested or sometimes paged into storage until memory is freed up.

//2 examples needed

Context Switching

In most computers, or other modern hardware such as phones, there will be lots of processes active at the same time. One will be running on each core of the computer’s processor (in a single threaded CPU, in most modern CPUs more than one thread can run simultaneously thanks to multithreading), the others will be queued within the scheduler. The scheduler performs context switches periodically to allow each task its chance to perform its operation, this is triggered when the threads quantum runs out. A quantum is the maximum amount of time a process is allowed to run before being switched out for another thread of similar priority. Usually this switch is fast, making it appear as though the processes are running simultaneously (Brockway, 2019).

However on many occasions a process can require access to an additional resource which is not readily available, for example access to network I/O or a hard disk drive. If the resource manager cannot grant access to this quickly, the process is paused and a context switch occurs. The scheduler saves the context of the current thread into a waiting state, where it waits for the resource to become available, while it waits the next process in the queue is loaded into the processor and worked on (Neville-Neil and McKusick, 2005). While the process of context switching is expensive, due to the volatile data like registers, the program counter and memory data having to be transferred into storage, it can speed up computers as less time is spent waiting for access to resources and it is a vital process in any multitasking machine. The scheduler moves the process into a waiting state where it waits for the resource to be available, then when it is possible the scheduler resumes the process.

A context switch can also be caused hardware interrupt. A hardware interrupt is a signal from a hardware device, for example a mouse or keyboard, to the operating system kernel that an event has occurred, which can be anything from a key press to network data arrival as discussed by (The Linux Information Project, 2006).

//consider more

Secure Socket Layer

Secure Sockets Layer (SSL) is a widely used security protocol, supported by almost all web browsers and major operating systems. It has become the security standard for establishing an encrypted link between a web server and a browser. It provides authentication, confidentiality and integrity to internet users (Kurose and Ross, 2016).

When authenticating the server, the client uses the server’s public key to encrypt the data that is used to compute the secret key. The server can then decrypt the message including the secret key only if it can decrypt that data with the it’s private key. For client authentication, the server uses the public key in the client’s certificate to decrypt the data the client sends during the handshake. The exchange of finished messages that are encrypted with the secret key confirms that authentication is complete  as stated by (IBM Knowledge Center, 2019a).

SSL uses a combination of symmetric and asymmetric encryption to ensure message privacy and confidentiality. During the  handshake, the SSL client and server agree an encryption algorithm and a shared secret key to be used for one session only. All messages sent between the client and server, using SSL, are encrypted using the chosen algorithm and key, ensuring that the message remains private even if it is intercepted (IBM Knowledge Center, 2019a).

SSL can confirm the integrity of any sent data by calculating a message digest. The message digest is a fixed size numeric representation of the contents of a message, computed by a hash function. This message digest can then be encrypted, and used as a digital signature (IBM Knowledge Center, 2019b).

Secure Socket Layer Cryptography

SSL encrypts sensitive information so that only the intended recipient can access it, confirming that all data that is sent is protected. This is important because the information you send on the internet is passed across many computers in order to reach the destination server. Without SSL’s encryption any computer between yours and the server would be able to read your private data including; your credit card details, passwords, and other sensitive information. When SSL encryption is used, the data becomes unreadable to anyone except for the server you are sending the information to as detailed by (SSL Shopper, n.d.). There are 2 types of SSL encryption, symmetric and asymmetric. Asymmetric keys are bigger than symmetric keys, meaning the data that is encrypted is tougher to crack. However, this does not mean that asymmetric keys are better.

As described by (Digicert, n.d.), symmetric keys require less computational burden to encrypt and decrypt and the same key is used for symmetric encryption and decryption. Due to this, both you and the recipient need the key. This means that, if you need to send the key, serious security risks arise as if the key is intercepted, anyone with the key can decrypt the data.

Asymmetric encryption doesn’t have this problem. As long as your private key is kept secret, no one can decrypt the messages sent to you. Your public key can be sent to anyone, without worrying about any security risk. Anyone who has the public key can encrypt data, but only the person with the private key can decrypt it. Asymmetric encryption has many uses, the

//2 examples needed 1 symmetric 1 asymmetric

Man-in-the-Middle Attacks

A man-in-the-middle attack is when the communication between two systems is intercepted by a third party. The man-in-the-middle attack can intercept the public keys, as described by (Oracle, 2010), that are exchanged during the SSL handshake and switches them with his own. This makes it appear to the client and server that each is in contact with the other. This allows the man-in-the-middle to change any information passed between the client and server. However, in this case, he cannot read any of the data sent.

SSL can be vulnerable to man-in-the-middle attacks, according to (Mutton, 2016), 95% of HTTPS servers are vulnerable to trivial attacks, but this is usually due to the server host’s ignorance. Man-in-the-middle vulnerabilities on SSL secured sites are usually caused by one of SSL’s security preconditions being broken. An example of this would be if the server’s private key decryption key is stolen, the attacker can pretend to be the server without the client ever knowing.

References

• Rouse, M. (2005) Hardware Abstraction Layer (HAL). Available at: https://whatis.techtarget.com/definition/hardware-abstraction-layer-HAL (Accessed: 08/05/19).
• Kendall, D. (2019) Computer Networks, Security, and Operating Systems [Lecture], KV5002. Northumbria University. 28/01.
• Eizikovich, S. (2016) Standard versus Virtual Joystick. Available at: http://vjoystick.sourceforge.net/site/index.php/dev216/112-system-architecture216 (Accessed: 08/05/19).
• Tanenbaum, A. S. and Bos, H. (2014) Modern Operating Systems. New Jersey: Pearson. Volume 4.
• Brockway, M. (2019) Operating Systems & Concurrency: Process Concepts [Lecture], KV5002. Northumbria University. 28/01.
• Neville-Neil, G. V. and McKusick, M. K. (2005) FreeBSD Process Management. Available at: http://www.informit.com/articles/article.aspx?p=366888&seqNum=3 (Accessed: 09/05/19).
• The Linux Information Project (2006) Context Switch Definition. Available at: http://www.linfo.org/context_switch.html (Accessed: 09/05/19).
• Kurose, J. and Ross, K. (2016) Computer Networking: A Top Down Approach. New Jersey: Pearson. 7th Edition.
• IBM Knowledge Center (2019a) How SSL and TLS provide identification, authentication, confidentiality, and integrity. Available at:https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q009940_.htm (Accessed: 10/05/19)
• IBM Knowledge Center (2019b) Message digests and digital signatures. Available at: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.1.0/com.ibm.mq.doc/sy10510_.htm (Accessed: 10/05/19)
• Almeida, R. (2017) Symmetric and Asymmetric Encryption. Available at: https://hackernoon.com/symmetric-and-asymmetric-encryption-5122f9ec65b1 (Accessed: 11/05/19)
• SSL Shopper (no date) Why SSL? The Purpose of using SSL Certificates. Available at: https://www.sslshopper.com/why-ssl-the-purpose-of-using-ssl-certificates.html (Accessed: 12/05/19)
• Digicert (no date) Behind the Scenes of SSL Cryptography. Available at: https://www.digicert.com/ssl-cryptography.htm (Accessed: 12/05/19)
• Oracle (2010) Man-In-the-Middle Attack. Available at: https://docs.oracle.com/cd/E19656-01/821-1507/aakhd/index.html (Accessed: 12/05/19)
• Mutton, P. (2016) 95% of HTTPS servers vulnerable to trivial MITM attack. Available at: https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html (Accessed: 12/05/19)