代写SE 3313A、代做Operating Systems、Java语言代做、Java编程设计调试

日期：2019-11-26 10:39

SE 3313A – Operating Systems

Design Project: Multi-User

Multi-Transaction Server

Design Project

2

SE 3313A – Multi-User Multi-Transaction Server

I. Objective

The project ties together the elements you have been using in the labs to create a multi-user,

multi-transaction server. This will give you the ability to apply threads, thread

synchronization (semaphores and so on), and parallel processing in ways that will give you

a new view of what they can do.

II. Introduction

You will require different information to complete this project.

The contents of this document explain only what is expected. Additional documents are

available that describe various resources for this project. Moreover, you may find resources

provided with labs beneficial too.

I would like you to work in groups of 3-4.

III. A Multi-User Multi-Transaction Server

Your multi-transaction, multi-user server MUST conform to the following:

? The server MUST run in the UNIX/LINUX environment. You can host your server on

Amazon (AWS instructions provided in a separate document), with a different cloud

provider or on another computer of your choice. Keep in mind, that if you are working

behind a router (maybe at home you are using a router) or firewall, you may need to

forward or open ports.

? The server MUST run in a different physical environment (machine) than the clients.

Running the server on VM and a client on machine hosting this VM does not comply

with this requirement.

? Each transaction MUST have AT LEAST two participating clients.

? There should in principle be NO LIMIT to the number of simultaneous possible

transactions.

? Termination MUST be graceful. That means transactions clean up after themselves

in a graceful way. It also means that terminating the server terminates all associated

transactions in a graceful way. “Graceful” means without core dumps, unhandled

exceptions, the need to kill the process and so on. However, “graceful” DOES NOT

mean “polite”. A client can be unceremoniously booted out of a transaction, as long as

no crashes occur.

The project is flexible with respect to the following:

? The client can run in whatever environment (or set of environments) you like.

Possibilities include Android and Java clients. “Skin” for Java will be provided and you

can customize it for your project.

Design Project

3

? The definition of what is a “transaction” is entirely up to you. Could be a game

instance, a chat room, some kind of social media thing, or something else.

? The decision on whether NEW users can choose to join a transaction already in

progress is entirely up to you.

Deliverables

1. Submit group member names by Thursday, Nov 14th on: Group Members

Only submit one entry per group

2. High level design document – pdf file.

Submit in OWL. DEADLINE FOR ALL GROUPS Monday, Dec 2nd, 11:55 pm

This document needs to show the overall design. Examples of things to include: How

the various parts of your application work together? How many threads do you

need? What sort of synchronization objects do you use and how? How do you handle

termination?

3. ZIP file with code

Submit in OWL. DEADLINE FOR ALL GROUPS Monday Dec 2nd, 11:55 pm

? Name your submission: se3313a-usernameStudent1-

usernameStudent2- usernameStudent3.zip.

? There should be only one submission per group.

4. Mandatory demo during lab sessions. All group members must be present for the

demo.

? Section 002: Tuesday, Dec 3rd at 2:30 pm

? Section 003: Wednesday, Dec 4th at 3:30 pm

? Section 004: Thursday, Dec 5rd at 8:30 am

If the group did not demo the solution during the lab session, the group must contact

the professor as soon as possible to arrange the time for the demo.