A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system. The Middleware is the same to a distributed system as what an operating system is to a computer.
The important goals that should be met to make building a distributed system worth the effort are:
A distributed system:
- should make resources easily accessible.
- should hide the fact that resources are distributed across a network.
- should be open
- should be scalable.
The middleware assist the development of distributed applications and it is considered as a manager of resources offering its ap- plications to efficiently share and deploy those resources across a network.
Next to resource management, it offers services that can also be found in most operating systems. The main difference, is that middleware services are offered in a networked environment.
| ID | Use-Case | Description |
|---|---|---|
| UC01 | offer services | as an application I want to specify and offer my services |
| UC02 | lookup services | as an application I want to lookup and use the offered services |
| UC03 | invoke functions | as an application i want to invoke a function that is implemented and executed on a remote computer as if it was locally available. |
| ID | Goal | Description |
|---|---|---|
| QG01 | Access | Hide differences in data representation and how an object is accessed |
| QG02 | Location | Hide where an object is located |
| QG03 | Relocation | Hide that an object may be moved to another location while in use |
| QG04 | Migration | Hide that an object may move to another location |
| QG05 | Replication | Hide that an object is replicated |
| QG06 | Concurrency | Hide that an object may be shared by several independent users |
| QG07 | Failure | Hide the failure and recovery of an object |
| Role | Expectations |
|---|---|
| Customer |
|
| Application |
|
| Developer |
|
| ID | Constraint | Description |
|---|---|---|
| TC01 | Programing language | Implementation in an object-oriented language |
| TC02 | Implementation |
|
| TC04 | Frameworks | The use of frameworks must be approved by the customer |
| ID | Constraint | Description |
|---|---|---|
| OC01 | Documentation | clear representation of the structure in at least 2 hierarchy levels: component diagram, class diagram, deployment diagram (ARC42) |
| OC02 | Project Management | fixed method for project management (proof) |
| OC03 | Problem Solving | problem-solving strategies must be derived from reference literature or accepted third-party literature |
| OC04 | Deadline | project musst be delivered by 27.01.2022 23:59 UTC |
| Actor | Function | UCID | Semantics | Precondition | Postcondition |
|---|---|---|---|---|---|
| ServerStub | void start() | UC01 | starts the rpc server which setup a udp and tcp server on the same port and start listening for income sockets | rpc receiver is up and listening on a random port | |
| ServerStub | void receive() | UC01 | accept incoming sockets and forward the data to the rpc unmarshaller | rpc receiver was started | the server thread is blocked until socket connections are made |
| ServerStub | void register(IRpcCalleeAppStub rpcCalleeAppStub) | UC01 | register a services to be called if a rpc call was made to the same service id | rpc server stub was initialised | the service is registered and can be called |
| Discover | static InetSocketAddress discover() | UC01 | start listening on the specified discovery address and port | the directory server address was discovered and returned | |
| DirectoryServer | void register(IDirectoryEntry directoryEntry) | UC01 | register a service to announce to listeners | the directory server is up and running on a node | the service is registered and will be announced to current listeners |
| DirectoryServer | void addListenerTo(UUID serviceId, InvalidationListener listener) | UC02 | offers a push approach to lookup all services under the same service id | all new services with the same service id will be announced to service listeners | |
| ClientStub | void invoke(UUID serviceId, IRpcCallbackHandler rpcCallbackHandler, boolean isBestEffort, Method method, Object... args) | UC03 | forwards the invoked function with application stub preferences to the rpc marshaller | application called a function on a remote service | rpc marshaller received the function call and started the marshalling process |
| Callback | void register(UUID requestId, IRpcCallbackHandler rpcCallbackHandler) | UC03 | registers a callback handler that will be invoked when the result of the request/invocation was received | rpc callback handler was provided which implies that the application is awaiting a callback | the handler is registered and can be used by a callback |
| Callback | void retrn(UUID requestId, Object result) | UC03 | sets the invocation result of the rpc call for the callback handler | a handler exists under the same request id otherwise the result is dropped | the callback handler is invoked with the received result |
| Component | Description |
|---|---|
| RPC | allow programs to call procedures located on other machines |
| DirectoryServer | holds and shares all Network relevant information about other participants of the distributed System |
| DiscoveryService | handles announcing and discovering messages on the local-network |
| Interface | Description |
|---|---|
| IRpcCallerAppStub | to be implemented when RPC calls are to be made on a service |
| IRpcClientStub | dose the RPC call on behalf of the application stub |
| IRpcCallbackHandler | handles the callback result |
| IRpcServerStub | handles RPC calls and forward them to the application stub of the service to be called |
| IRpcCalleeAppStub | to be implemented when RPC's are offered from a service |
| Interface | Description |
|---|---|
| IDirectoryService | keep track of all offered services and announce them to interested listeners |
| Interface | Description |
|---|---|
| IDiscoveryServer | broadcast Announcements over the Network |
| IDiscoveryClient | listening for the discovery Server Announcements and handle them |
| Component | Description |
|---|---|
| ApplicationStub | handles the Interfacing with the Middleware |
| ClientStub | dose RPC calls based on the application stub demand |
| Marshal | marshals the function to be invoked and it's parameter to be sent over the network |
| Send | sends the marshaled function over the network |
| Message | handles meta-information to pack functions and its parameters into RPC Requests |
| Receive | receives RPC calls and forward them to the unmarshaller |
| Unmarshal | parses RPC calls and forward them to the server stub to be called |
| ServerStub | calls the application stub of the received function to be called and do callback if needed |
| Callback | Handles the Callback of RPC Call invocation result |
| Interface | Description |
|---|---|
| IRpcSender | sends the parsed rpc request over the Network |
| Interface | Description |
|---|---|
| IRpcMessageApi | handles meta-information to pack functions and its parameters into RPC Requests |
| Interface | Description |
|---|---|
| IRpcCallbackService | handles the registration of callback handlers and invoke them when receiving the result |
| IRpcCallback | returns the result of a RPC Call |
| Interface | Description |
|---|---|
| IRpcUnmarshaller | unmarshals the received RPC request into a RPC Call |
| IRpcServerStub | Interface for a Server Stub which handles a list of all Methods it can call |
| Component | Description |
|---|---|
| Discovery | handles announcing and discovering the directory server address |
| Interface | Description |
|---|---|
| IDirectoryEntry | a service entry that can be registered and announced |
fault tolerance is not a requirement and therefore all sequences describe the best case scenario
in this case the directory service is mainly used as a source of truth for the remote game rooms, therefore implementing it to be observable offer the system a quick and easy way to get the new rooms available without actively pulling or refreshing.
this push approach is also helpful when the state of the room changes weather removed or full which in both cases changes the service reachability and pushes the update immediately to be reflected on all listing nodes
structured naming or "human-readable" names play no important rule in this system. RemoteRooms are mainly distribute which are grouped under the same service id therefore implementing a very simplified directory server serves the use-cases of this system (the expensive lookup/search and/or the complex mapping of attributes are not a problem for the system use-cases).
a centralized component is often used to handle initial requests, for example to redirect a client to a replica server, which, in turn, may be part of a peer-to-peer network as is the case in BitTorrent-based systems. Page 102
in this case the directory server serves exactly this purpose and provides the players with the opponent address to initiate the peer to peer "connection"
To synchronize logical clocks, Lamport defined a relation called happens- before. The expression a → b is read “event a happens before event b” and means that all processes agree that first event a occurs, then afterward, event b occurs. Page 311
Lamport’s logical clocks fits the use-cases of this system perfectly and were actually indirectly implemented in the game as the application mostly relays on the observable pattern und need to ensure fairness between players a coordination system using the PlayerUpdate version was implemented in the GameUpdater. This implementation can be considered as a basic implementation of the lamport Lamport’s logical clocks