Repository navigation
1. Concept
The communication architecture is basically a comet pattern. Any client, regardless of which kind, can call a certain listener route and will receive a long polling http handle on which all incoming messages transfered instantly. If a client needs to send a message, it will call a parameterized (static) url to inject a new message into the communication lifecycle of the backend. The backend is able to switch messages directly to related receivers and will deliver the messages via the long polling comet routes.
Note: To be prepared for any kind of firewall configurations within the network or the serving system, the communication is completly processable over one single port. By default it would be the Tomcat destination port e.g. 8080. But you can use any other port if you want to.
The modular and high flexible structure of UniBoxServer is split into several packages.
To get a more detailed overview you can take a look at the UML Class Diagram of the current state.
The Client API is accessible through the ClientProvider class located in the de.unibox.client.api package. It is a static Wrapper-Class which gives access to all needed functionalities provided by the backend.
To get a more detailed overview you can take a look at the UML Class Diagram of the current state.
The UniBoxCore centralized the intersection-classes of UniBoxServer and UniBoxClient.
To get a more detailed overview you can take a look at the UML Class Diagram of the current state.
