Ricky Landry

COP5611 – OS Design Principles

Project Phase 1 Report

Some unforeseen limitations in the effort that was able to be put into phase 1 arose and the ambitious schedule of deliverables from the phase 0 proposal will no longer be realistically obtainable. Originally, phase 3 was intended to simply be a polish period. With the project being behind on estimated effort and schedule, resources allocated to polishing of the completed project will be diverted to the development effort planned for phase 2. As a consequence, the high level design of components and interfaces will be completed during phase 2.

Although this is disappointing news, it should not affect the fundamental envisioning of the end product. The schedule for the project has been re-evaluated and by redirecting effort and schedule from phase 3, the project should still be completed by the final delivery date. The project will need to be closely monitored, and some of the more complex, but non-essential, usability features will most likely not be considered during the implementation phase.

At this point, the behavior of the design has been articulated from a high level and some design/implementation concerns have been noted. This articulation will allow for a clearer and more efficient design of the components, interfaces, and protocols required, which will take place during the first half of phase 2. The results of this articulation have been included below.

Behavior

  • Server keeps record of current top-level thread messages and any comments (child messages) associated with those thread messages.
  • Thread messages are constant and cannot be edited. Can be deleted, but only by thread author.
  • Comment messages are constant and cannot be edited. Can be deleted by thread author AND comment author.
  • Client, on startup, will request initial messages from server, which will consist of ALL thread messages present on server. Server will compare last revision for that user for each thread and will flag any threads that have been updated since last login.
  • Server will maintain, for each thread, a list of tuples that contain the users that have downloaded the threads and the revision that they received. This will be used to determine when to flag threads that have been changed since the user logged off.
  • The “revision” is defined as a unique identifier that will be used to distinguish between different instances of a single thread that have differing content. This, as discussed in the implications section, may consist of a combination of sequence number and server timestamp.
  • Subscription to a thread is defined as the user having “followed”, “commented”, or authored a thread.
  • The server will maintain a list of subscribers for each thread.
  • The server will attempt to send notifications of thread changes to users that are online. These notifications will contain the identifier of the thread that has changed and the notification type. There will be two types of notifications, general and subscribed. These may be used by the client to notify the user differently when a change is made to a subscribed thread than to any other thread that may or may not be of interest.
  • When a client receives a change notification, it will request an update from the server of the thread identifier present in the notification. If the notification is of general type,the client may passively indicate a change to the thread via the viewer (i.e. bold the thread header text). If the notification is of subscribed type, the client may notify the user in a more proactive manner (i.e. bold text as for general, but also make an entry in a list of subscription notifications present in the client.
  • When a client requests a thread update from the server, the client will include the thread identifier and revision in the request. The server will respond with a package containing any additions or removals to the comments of a thread, or a message reporting the deletion of said thread.
  • “Online” is defined as a user currently being logged into the server. This means that the client should make every effort to communicate a sign out when the application is terminated. A keep-alive messagefrom client to server may be implemented to allow server to log users out that have clients that terminate unexpectedly.
  • The server will maintain a list of onlineclients and their respective sockets for receiving notifications.
  • The client will see a list of thread messages and will have options to view “Comments…” on the thread and “Follow” the thread. When viewing messages (either list of threads or comments on a specific thread), a “Delete...” option will be present if the user associated with the client is the author. If this “Delete…” option is selected, a confirmation dialog will appear to reduce risk of human error and if confirmed, final authentication of permission will take place server-side.
  • When the client selects to view the comments on a thread, the client will fetch (on first time ALL comments, updates on any additional views) comments and an additional window will appear displaying those contents.
  • When changes (“Follows” or “Comments”) are made to a thread, notifications that a change has occurred will be sent to the clients of users that are “online”. This can be used by the client to determine if any dynamic updating of the viewer needs to occur (i.e. if a follow or comment is added to a thread that is currently being viewed).

Implications, Potential Implementation Ideas, and Misc. Notes

  • Because messages cannot be edited, hashes (which will be used to refer to messages) will not change. There should be a way to be able to keep track of changes within a thread. This could be accomplished by including some sort of sequence number for the thread messages. This approach alone could yield a situation where sequence number rollover prevents a client from getting a proper update to a thread. To combat this, a server timestamp of the last update time could be sufficient in combatting this. The sequence number could allow for distinguishing multiple events that occur within one unit of server time resolution, and the server timestamp allows for distinguishing between identical sequence numbers that represent different content. Although it is theoretically possible that sequence rollover could occur within a single unit of time resolution, this will be highly improbable in practice.
  • The Serialization interface of Java can most likely be used to encapsulate the message data for transfer between server and client. This interface should allow for deep copying of message objects, which would greatly simplify the transfer process.
  • Although revisions will be used to determine when thread content is out of sync between client and server, the client will need to fetch ALL content when a thread is viewed for the first time. The server keeping track of the user’s revision history will be useful in notifying the user if the state of the thread content has changed since the previous session.
  • Client should have some method of manually refreshing in the event that notifications from the server are lost in transit. This will probably not need to be used often in practice, especially when considering that even UDP is incredibly reliable these days, but could be useful for user sanity checking.
  • Thread headers should definitely have a limited number of characters, essentially being topic descriptors as opposed to messages containing any amount of content themselves. Comment messages may also be limited in size, but can be considerably larger than thread headers.
  • We may want to strongly consider the use of TCP when transmitting message content objects. Notifications of content change events from server to client would probably be sufficient to transmit via UDP, since if the notification is lost, it simply means that the client will not be aware that a change has been made.
  • It will be important to ensure that duplicates of the same message are not displayed in the client. The risk of this occurring in a system in which comment message identifiers do not change for identical content should be fairly low. Since only revisions will change, it should be easy to identify the message that has changed and simply overwrite it with the new revision.
  • Currently, no intention of providing persistence of content on termination of the server is being considered. It could be implemented, time permitting, as a crude periodic dump to a file. If this were to happen, it would be best to design the server state as its own object containing all of the database and state information about the users. This would allow for quicker implementation of backup capability as it may be possible to simply implement the Serializable interface and write the entire server state object to a binary file periodically. If this were to be included, it could be possible to keep a history of the server states in the event that a bot attack or spamming were to occur. The server could be “rolled back” to a previous state before the incident occurred (with a risk of losing any valid content generated during the attack, of course).
  • It is currently decided that an MD5 or SHA1 hash would be sufficient for user/pass hashes and message identifiers. The java.security.MessageDigestclass, provided in the Java standard API, should be sufficient for this task. Most likely, hashes for the message identifiers should be computed solely on the text content of that message. If message id hashes were computed on the objects themselves, they may change as the revision changes, would complicate client/server content synchronization.