i am trying to create framework/library /API for creating small multiuser games, in which the goal is to achieve 'decoupling' between the server, client and business logic.
The server in my case is kind of registering the clients and sent that
list to business logic, clients are registering with the server,
and the business logic do the game logic stuff and updates the client by getting the list of client from server.
But currently,
i have only one class, so its trivial but this could consist of several game objects
(and what would be the role of classes serialized/remote
like the game engine, player, score, move, board).
i decided to use the RMI for this and this will definitely use callback
mechanism can somebody told me.
How could i achieve this encorporating all the requirement of server updating clients (callbacks).
PS:i m currently working on the design, which has one remote/serialized object for handling gamelogic but i wanted to
use other classes as i mentioned for sake of making multiuser game library and to show the use of important classes in it as an example.
thanks a lot
jibby
If you are intending this framework to work for real time games then I would advise against using RMI - it isn't really designed for that sort of thing. Also be aware that two-way RMI between machines on different subnets is very hard to get working.
It seems as if you need the clients to be informed by the server when events occur. When your client connects it can lookup a Remote object from the server's RMI registry and call a method on that to pass a Remote object it has created (hosted on the client) to the server. The server will have to maintain a collection of these client objects and iterate through them to send events. This is a tricky architecture to get right as if the network goes down or a client goes offline you will have to deal with all sorts of nasty error handling and freeze ups. I would recommend you keep the majority of communication in one direction - from client to server. Also keep it as simple as possible - simply a Remote object on the server with various methods that take Serializables as parameters and return Serializables.
Whether or not this is MVC depends on your interpretation. You could see the clients as views with the model and controller on the server in which case it is MVC with the event mechanism being a remote implementation of the observer pattern.
The trickiest part of the task will definitely be getting the code on the server that notifies the clients correct as it will need to be multi-threaded and handle errors gracefully - good luck!
Related
So I have a REST api. I want to keep it stateless, but at the sametime I need to make a real time chat.
The only way I can imagine a real time chat, is with websockets. The problem accurs that websockets, to my knowledge, seems pretty statefull.
Is there another way to create a real time chat?
My stack is Spring boot (java)
React frontend
Mongodb for database.
Plan for hosting would be AWS
And normally I would just ignore the 100% stateless or statefull, but this is for a school project, and I would look good in my report, to say I am 100% stateless.
the correct way achieving real time chats beside websockets would be to use firebase which is very common since usually the clients connected to your server will use android/iOS.
obviously an app connected to firebase is maintaining a stateful connection to firebase.
in general i dont think it is possible to provide push functionalities without state , as the server must reach the connected clients thus it must maintain those connections. if not using firebase, using websocket seems a reasonable approach.
I know two ways of implementation this. Easiest - websockets. Hardest - backend is calling frontend.
More about second solution. In normal world, we are calling backend using frontend, here will be visa versa. When backend will receive a message (from another user), it will tell frontend that message was received ant it should show it.
Consider this scenario: I have N>2 software components (microservices) that can communicate through two different communication protocols depending on how they are deployed. In other words, I have two deployment scenarios:
The components are to be deployed on the same machine. In this case I don't know if it makes sense to use HTTP to communicate these two components, if I think about performance. I understand that there are more efficient ways to communicate two processes on the same machine using java, such as sockets, RMI, RPC ...
The components are to be deployed on N different machines. In this case, it seems to me that it makes sense for me to use HTTP to communicate these components.
In short, what I want to do is to be able to configure the communication protocol depending on the way I perform the deployment: On a single machine, for example, use RMI, but when I deploy on two machines, use HTTP.
Does anyone know how I can do this using Spring Boot?
Many Thanks!
Fundamental building block of protocols like RMI or HTTP is socket communication. If you are not looking for the comfort of HTTP or RMI, and priority is performance, pure socket communication is your choice.
This will raise other concerns like, deployment difficulties. You should know IP address of both nodes in advance.
Another option, is to go for unix -domain socket for within server communication. For that you have to depend on JunixSocket.
If you want to go another route, check all inter process communication options.
EDIT
As you said in comment "It is simply no longer a question of two components but of many". In that scenario, each component should be a micro-service And should be capable to interact with each other. If that is the choice most scalable protocol are REST/RPC both are using HTTP protocol under the hood. REST is ideal solution for an API to be developed against a data source using CRUD operations. RPC is more lean towards action oriented API. You can find more details to identify the difference in between REST and RPC here.
How I understand this is...
if the components (producer and consumer) are deployed on the same host then use an optimized protocol and if on different hosts then use HTTP(s)
Firstly, there must be a serious driver to go down this route. I take it the driver here is performance. You would like to offer faster performance on local deployment and compartively compromised speeds on distributed deployments. BTW, given that we are in a distributed deployment world (or atleast where we are headed) HTTP will be what will survive. Custom protocols are discouraged.
Anyways... I would say your producer application should be in a self healing / discovery mode. On start-up (or periodically) it could check the health of the "optimized" end-point and decide whether it the optimized receiver is around. The receiver would need to stand behind a load-balancer. If the receiver is not up then go towards HTTP(S) and setup this instance accordingly at runtime.
For the consumer, it would need to keep both the gates (HTTP and optimized) open. It should be ready to handle requests from either channel.
In SpringBoot you can have a healthCheck implmented and switch the emitter on/off depending on the health of optimized end-point. If both end-points are unhealthy then surely the producer cannot emit anything. Apart from this the rest is just normal dependency-injection.
I'm starting to develop what should become a client-server Application using Hibernate, Spring and Eclipse RCP (for the client). This is the first time I'm designing an application from the beginning so I'm just making my first steps.
I have set up Spring on both client and server using RMI for remoting (but I wouldn't mind using something else if there was a clear advantage). So right now I'm able to call exposed services of the server from different clients to get information from the database. What I haven't done is get any kind of authentication in place, so basically the server just answers to the different clients without knowing anything about them, there is not concept of a session yet. Of course this has to change since I need different user to have different roll and so on, but right now the problem I'm facing is getting the server to notify the client when certain thing happen.
My idea to solve this problem was to have a queue of events at the Server and have the clients get them every 3 second or so. The server would then identify the client by it's session token and send the appropriate events. Yet my partner in this project is concerned that this technique (polling) might waste too much bandwidth unnecessarily.
So to bring it to the point. What are the standard techniques for a server to notify a client about changes using Spring? Please notice that I'm not developing a web application and that this is only intended to be used withing a private network. That is one of the difficulties I've been facing: every single tutorial about Spring security or remoting assumes you are making a web application, but I really don't want to get lost into the details of Spring MVC and web applications in general.
Any resources would be appreciated. A good and long tutorial on the matter would be great.
EDIT: Hmm, it looks like JMS might be what I'm looking for.
As I understand, the issues you are facing is identifying a client in request and correlate different client request i.e. have something like a session.
Spring also support RMI over HTTP protocol (Using Hessian and its own HTTP Invokers). Check out this link (Section 17.3). Now once you have transport as HTTP, it has inherent Basic Authentication and session which can be leveraged to get around the issues you are facing.
This is just a pointer. I would be curious to know how eventually you resolved your problem.
Basically I need a bidirectional client-server communication (Java) where the client calls methods on the server, but also needs to get "callbacks" if certain events in the server occur.
The methods theirselves have quite complex input and output parameters and lateron it would be nice to include authentication to the system.
Which approach would fit my requirements?
I already build a prototype with RMI, but I read that there exists a number of problems especially for "callbacks" when the c/s are in different networks.
Additionally I would like to avoid JAX related technology, becuase of my complex data structures in the parameters.
Have you thought about using JMS. Within this architecture, server and client will register to a queue or topic and are able to send messages to each other. This enables sych and async application behaviour.
Please have a deeper look into JMS here:
http://java.sun.com/developer/technicalArticles/Ecommerce/jms/index.html
And a really nice implementation is ActiveMQ:
http://activemq.apache.org/
I've had lots of luck with using CometD for callbacks for webapps.
I have to design a distributed application composed by one server (developed in Java) and one or more remote GUI clients (Swing application with windows).
As stated before the clients are Swing GUI application that can connect to the server in order to receive and send data.
The communication is bidirectional (Server <=> Clients).
Data sent over the network is mainly composed by my domain logic objects.
Two brief examples: a client calls the server in order to receive data to populate a table inside a window; the server calls client in order to send data to refresh a specific widget (like a button).
The amount of data transmitted between server and clients and the frequency of the network calls are not particularly high.
Which technology do you suggest me for the server-clients communication?
I've in mind one technology suitable for me but I would like to know your opinions.
Thanks a lot.
The first technology that came to my mind was RMI - suitable if you're communicating between java client and java server. But you may get difficulties if you want do switch the client technology to - say - a webinterface.
I would go with RMI but implement the whole architecture using Spring framework. This way it is independent of technology used and can be switched to other ways of communication (such as HTTP or other ) with almost no coding.
UPDATE: And Spring will allow you to have none of RMI specific code.
I believe sockets should do the trick. They are flexible and not especially hard to code/maintain. Most entry level programmer should also be able to maintain them. They are also fast and adapt to any kind of environment.
Unless, your server is going to be off-site or you expect to have firewall issues. In that case, web services are the way to go since your basic communication happens through port 80.
I would second msparer's suggestion of RMI, except I would just use EJB3 (which uses RMI as the communication protocol). EJB3 are very easy and even if you don't use the other feaures EJB gives you (e.g., security) you can still leverage Container Managed Transactions (CMT). It really does make development easy.
As for the server->client communication, you would probably want to use JMS. Again, using EJB3 this is pretty e3asy to do with annotations. The clients will subscribe to the message service and receive update notifications from the server.
And yes, I am currently working on an application that does this very thing. Unfortunately we are using EJB2.1. Still, it is my opinion that this is where EJBs really shine. Using EJBs in a web app is frequently overkill, but in a distributed client/server app they work very well.
You can try using ICE http://www.zeroc.com for establishing server-client connection.