I've created a gameserver containing an ArrayList of players (Player). However, as far as i've been able to read, Kryonet can't send objects with a constructor in it to the client (Player have that), so i need to find an alternate way of transferring the ArrayList.
What would be a proper way to accomplish this?
You could use JMS implementation (in my case it ActiveMq) and send a Object message.
You just need to make the object have a default constructor with no arguments. you can still create the object with a constructor that takes in parameters.
Related
dear stackoverflow community.
Currently, I am working on a project. This project shall have a server and clients connecting to it. Because of their simplicity, I'd like to use Java's integrated ServerSockets and Sockets.
In my project, data shall be sent from the client to the server and opposite.
My initial idea is to just send JSON and then parse it as receiver and get the data from that.
I'm a little unsure about that though, since JSON isn't something that's integrated into Java, but comes from Java script. Also, I'm currently using a Multithreaded-Socket-Server, so I have a ClientHandler Thread class. In that class, the messages were received, parsed and the "action" parameter was read out of the JSON and then I did a switch statement with multiple actions and their functions. I don't think that's a good way of doing that either.
So, my question is:
How can I do that better, and maybe do I have to use something else?
Thanks in advance.
It is true that JSON grew out of JavaScript, but it is a reasonable definition language on its own and I don't see any reason you shouldn't use it. There are libraries for parsing it so you don't have to.
Assuming your JSON structures are different for different purposes, and complex enough to need different classes to represent them, I like the idea of the JSON having a parameter that identifies the class to which it belongs, after which you can hand off parsing to a class that understands the designated output. Then a class can read the JSON, get the type, and some the specific parsing routine can go from there to an object created for the purpose.
I don't see anything wrong with an action string, either; it's served well enough for Swing and some other UIs, after all. Instead of branching out to a function, depending on complexity again, you could have action classes that all implemented an interface, and the action 'verb' could tell you which one (out of a map, say?) to get and execute the 'performAction()' method on or whatever you want to call it.
I don't know how clear this is from a quick description; would be willing to chat about it in an SO chat room if you care about it.
i am working on a chat program.
[JAVA] [Without RMI, just Sockets] [Command example: 'sentToMike', 'Disconnect', 'Login', etc]
How do i send a "command" Object through Sockets to be excecuted on the server directly?
I want to send all kind of messages(Strings, Audio, Video), and all kind of Command objects to many clients, any of them. I know there exist ObjectInput/Output objects and all of that. My problem is trying to get a polymorphic solution.
For example i want to create a IMessage interface with a method signature "execute()". Then i would create a AudioMessage, TextMessage, etc that implements the IMessage. The problem is that at some point i need to share the server code with the client and viceversa in order Server and client know all the objects involved in every excecute method. And worst of all is that if i send an IMessage, the server would't know what specific type the message is, so i dont know to what kind cast the Object. The same would happen when i send the Command back to the client.
I can work a solution with simple text strings "commands" and a big and ugly switch in the server(and in the client by the way), but i believe that is not elegant, i would need to create a wrapper class with the string command plus the object of the kind i want to send plus the string with the type of object been sent(Message[String type; String command; IMessage->AudioMessage ]), this wont be polymorphic since i will need to use the switch to ask the type of the object and then cast it to AudioMessage for example. Furthermore i would need to share a lot of code between server and client and i dont know if that would be ok.
Any advice will be very very welcome, maybe i need a design pattern, an architecture pattern, i have no clue.
There are security reason to not allow just any code to run on server!
But if you are willing to expose your server (and client) to unknown code, then you need to also serve classes bytecode, and have classloaders to enable instanciating classes' types you expect the other end to accept. Your protocol would have to send the full classname and locations (if not inlining the bytecode) of the alien class (and all its dependencies not found in parent classloader), for the purpose of hoping to call any method of such object.
(FYI, that just reinventing RMI).
If you don't have to call anything on this object (it's not your case, I know, but I musy say it), then it is passive and there is really no point in transporting it as an object instance.
I want to make a small network game of two clients sending messages to eachother.
I'm new to sockets and serialization but I read that sending serialized objects via sockets is the way to do.
My problem is, I have multiple types of messages. One might be a simple chat message, the other one a turn (message) like a "NewObjectMessage" or "MoveObjectMessage"...
In tutorials I always read something like
MyClass myClass = (MyClass) objectinputstream.readObject();
which does a casting to the one specific class I put in the stream on the other side.
Question is: is there any way of determining what kind of message I get?
I'm looking for something like
stream.peekObject()
or something in order to see it's type.
Or is the common way to send two messages and the first one is only a declaration telling what comes next? But what happens if some packages get mixed up and the next object is not the one I was asking for?
So what is the best way to communicate between the clients in a way of e.g. moving an object and creating an object (or writing a message etc.)?
Thanks for your help!
Just read the object as an Object, and use instanceof to see what type it is.
Or have the objects all implement a common interface with an action method and just cast to the interface and call the method.
I think what you are looking for is object.getClass().getName();.
I am sending some packets through kryonet that simply hold an "Entity" variable. I created the entity class myself. The thing is that when registering the entity class, the class file on the server and the client are not exactly the same.
On the client side, I did not include some methods because they rely on accessing variable that are only server side and I completely removed all constructors because the client will not be the one creating entities, the server will. On the server wide I left out the render method since the server will not be rendering.
Does it really matter what methods and constructors are there? Does kryonet only look to see if the variables are the same (cause they are)? Thanks!
By the way, if you were wondering, Entity is an abstract method and therefore when I create new types of entities like "Player" for example, they extend it and add even more methods and variable. I hope that is alright for sending those in a packet too.
I am not sure what you are asking but as far as I understand I will try my best to answer your question.
So I think what you are trying to do is you have a base class called Entity and you extend it to different classes. You implement some methods in class which will be sent to client and some which will be sent to server.
So as you asked does it matter what methods and constructor are there, the answer is NO. Till the time you have an empty Constructor (required by Kryo serializer) kryonet is fine with whatever constructor you have. Just you need to make sure you have an empty constructor. I have many classes in kryonet with more than 2 constructors and they work perfectly fine.
A tip, since you are sending data on network, if I was you I would have removed all the data variables which will not be used in client and abstracted out the classes even more.
Also why are you sending methods in classes? Just curious. I think you should have methods in server and client and you should take the data out of the packet (classes) and then send it to the method in your server or client.
If anything is not clear let me know.
I'm developing a simple Multicast networked program, and was just curious on the best class structure and OOD patterns that best suit a client/server or client/client network. My dilemma is that I will be sending different kind of messages via datagram, and the receiver just sees a bunch of bytes coming at them. Now, I already implemented a sort of "ID" placeholder as the first byte of all of my byte arrays to distinguish between a message containing "hello world" and one containing the coordinates of a user for instance. The only option seems to be to just have a huge set of case statements in my "receive" method based on what the "ID" is but this seems like bad practice. Just looking for ideas to take advantage of Java's OOD patterns and all-around good coding practice.
On a side note (I think this is somewhat related...) would it be advantageous for me to ues object streams instead? It seemed to me that I would still be checking instancof on everythign coming in. Thanks!
There are several possibilities, but the Strategy Pattern seems to fit the bill best.
In your situation, I would create an interface with at least two methods one to determine if the class can handle the message (which will check your ID bits) and another to actually process the message. Then you create a separate message processing class for each type of message.
Your incoming message handler would then have a set or list of these message processing objects (typically each of a different class, but all of whom implement the interface). When a message is received, the message handler would iterate through the message processing objects until one can handle the message is found, giving an error if no message processor will handle the message.
There are a few options here, depending on circumstances.
You can certainly send serialized objects, one for each message type. Serialized Java objects typically only work between Java apps, but you can aslo try protocol buffers for interoperable Objects (http://code.google.com/p/protobuf/)
You can send documents in an interoperable format like JSON or XML
You can make up your own format, and parse the text as you like
me, i would probably go with Protocol Buffers