elliottmb / 486project Goto Github PK

One of our first tasks is designing what layers of our application need to exist and how they should interact.

One common design idea is having Services which may or may not be running on different threads, that the main Application class keeps track of. These services would have synchronized methods for pushing and pulling data upon them. This may provide the easiest to implement architecture but has some SOC draw backs. (Need to getApplication().getSpecificService() a lot and make sure we're not holding onto access of anything.)

Other design ideas are having the core data living in a single container, with async tasks or runners that temporarily own a copy of the data to manipulate it. One issue here is checking ownership over time, especially with the database connection (since H2/Sqlite generally run embedded with minimal support for multiple connections unless you force it into server client mode)

Currently multiple clients can simultaneously be signed into the same user account.

No real downside other than a user experiencing differing ledgers over time if all instances aren't interconnected.

Possibly leave as is.

Ideally we should have a 'loading' type screen so that we can have it just spinning and saying "Connecting to Authority", so we can await the connection to the authority. Then once the connection comes through, the main thread would event trigger the connecting screen to transition to the login screen.

Also, it may be nice to have a "Retry" button that'll be able to be displayed if the connection to the central authority fails after x attempts.

General processing

Currently datagrams that need a parent are pushed into a waiting queue, but that queue is never processed. There are steps which need to be laid out in that area, which haven't fully been considered.

Essentially, an item in the "waiting" queue has had a ParentsOfRequest or AncestorsOfRequest dispatched. At this time, the former is the only one dispatched as the criteria for switching to the latter hasn't been formalized.

Once in the waiting queue, there is an AtomicLong attached to check for how long it's been in the queue. (Incremented on access)

In the waiting queue, when accessed, we need to check if we have the parents in the database at this time. If we have, we can move to the ready queue. If not, we need to check if the parents are in the toProcess or waiting queues. If they are, pop back on the waiting queue.

AncestorsOfRequest criteria

Essentially, when a chain of ParentsOfRequests have been made and co-exist in the waiting queue, we should consider doing an AncestorsOfRequest for the oldest generation. I believe a threshold of three generations may be the point to do this, as there would only be at most 4 grand parents to request ancestors of.
To check if we're in this state, instead of naively requesting parentsof as we currently are within the toProcess step, we should check if the current datagram is the parent of a datagram in the waiting queue, and if that child is a parent of datagram also in the waiting queue. If this is true, send a AncestorsOfRequest, otherwise ParentsOfRequest.

At this time, if the connection to the authority is lost, an exception is simply thrown and we do not handle it. There are a few routes to go, such as reattempting automatically, or showing a notice to the user in the UI and requesting that they reconnect.

In either case, the user is no longer "logged in" and this needs to be conveyed and we need to prevent message creation in the ui. (Disable submitting and have a notice.)

Due to the overpowering nature of Spring's dependency injection and containerization, the current project structure allows only one class using SpringApplication to exist. Therefore we need the following subprojects

• Client
• Central Authority
• Shared

This also entails communicating this information both to the UI, possibly through an ApplicationEvent that the ChatController listens for, and to the ClientManager to establish any not already established connections.

Continuation of #11

To facilitate pretty display of records, we need to actually know the username association with the UUID stored locally. A simple method for doing this is to provide the UUID -> Username pairing to authorized clients on login. The client then can store that in a map and reference it as needed for display.

This is a three stage issue. First stage is to be handled by Jake, implementing the message class and message sending on the authority side. Second stages I'll handle with implementing the map and exposing it safely. Third stage will be Ryan's integration with the UI.

Currently, only messages that are "submitted" are shown, and are shown before validation.

As we are using Apache Mina, we can take full advantage of Object serialization provided by Java or any custom serializer. As such, we can construct each network message (NM) or request and response as independent Classes and use the type system to guarantee safety.

At this time we've identified the following use cases / NM between clients

• NewMessageAnnouncement
  • When a client has successfully created and verified a message with the central authority, this message is sent out to all the other clients the originating client is currently connected to.
• LatestMessageRequest
  • When a client connects with another client, it will send this request to the client. (Unsure if we should do both directions or just the connecting client at this time)
• LatestMessageResponse
  • The response to the previous request, should contain the Message node that has the most recent timestamp
• ParentsOfRequest
• ParentsOfResponse
• AncestorsOfRequest
• AncestorsOfResponse

And the following for between the client and authority

• LoginRequest
• LoginResponse
• VerificationRequest
• VerificationResponse
• LogoutRequest
• LogoutResponse

Possible future messages that we may need, but not confirmed at this time:

• InvalidMessageNotice

Currently disabled, because it doesn't work properly. Despite the init(null, null, null) apparently grabbing default implementations as per the javadocs, it appears that it creates a non-usable state.

Currently when a client's consumer connects to another client's producer, the second client's consumer should connect to the first clients producer in kind, to create a query loop. This is currently not implemented, so communication is one sided. Some progress has been laid out for this, but I'm thinking the handler method currently in development may not be ideal, but instead an exchanging of peer information may work better upon connection.

For testing, we should have a method of connecting to a known ip and port. This will allow us to get client - client working while the authority components aren't finished

Currently, once you're logged in, there's no means to log back out.