When in simpleInitApp I use:
[java]Client client = new Client(hostname,TCPport, UDPport);[/java]
does it create a new thread itself, running in parallel way to the rest of simpleApplication?
I mean, while the application is modifying the positions of characterNodes within simpleUpdate loop, in the mean time the messageReceiver method of MessageAdapter is able to receive messages from server without interrupt the simpleApplication mentioned before?
c.
cardoppler said:
When in simpleInitApp I use:
[java]Client client = new Client(hostname,TCPport, UDPport);[/java]
does it create a new thread itself, running in parallel way to the rest of simpleApplication?
I mean, while the application is modifying the positions of characterNodes within simpleUpdate loop, in the mean time the messageReceiver method of MessageAdapter is able to receive messages from server without interrupt the simpleApplication mentioned before?
c.
Yes, the event listeners are executed in the network thread.
I would to be able to listen for new client connections, so the server could broadcast a message to the old clients telling that now a new client has been added to the group.
How can I put me between a new client connection on the server side?
I mean in the console log I can read the output:
19-dic-2010 15.12.16 com.jme3.network.connection.TCPConnection accept
INFO: [Server#1][TCP] A client connected with address /127.0.0.1
I've read Server,Client,MessageListener,ServiceManager classes but I still don't know how to do that.
Is it the right way? Have you tryed different methods to handle client connections?
Any suggestions?
Thank you in advance
c.
Try the ConnectionListener (I think it’s called). I’m at work atm. so can’t tell for sure, but I think that’s what it’s called. It has methods for detecting a new connection and a closed connection.
Yes, it’s true, I’m using it since a while. I forgot to write here the solution. Here for all who are interested:
[java]class MyConnectionListener implements ConnectionListene r{
@Override
public void clientConnected(Client client) { what do you want to do }
@Override
public void clientDisconnected(Client client) { what do you want to do }
}[/java]
Just wanted to post and say thanks for all of the useful information in this thread. It’s been a massive help.
If you have troubles/doubts or better ideas/solutions don’t hesitate to post here… Here we can share info that may be useful for other users!
Thank you, scrubalub for providing such valuable information.
Some example game/test is planned where you can see networking in action along with some graphical feedback.
[java]Yes, the event listeners are executed in the network thread.[/java]
So if I’ve created the main app extending the Application class, and within this, I’ve an instance of a client, I suppose I must tell the client to send my data updated in the Application’s update method. Isn’t it?
In this manner the program works with 2 separated thread, one for grafics and physics and the other dealing with the network. Right?
So, in theory, there will be any delay in the rendering loop caused by the client process of sending datas. Or will there be?
Or is better to create a completly separated “exchanging thread” which is in charge of sending and receiving data to/from the server in an asynchronous mode respect to the graphic thread?
Thanks
cardoppler said:
[java]Yes, the event listeners are executed in the network thread.[/java]
So if I've created the main app extending the Application class, and within this, I've an instance of a client, I suppose I must tell the client to send my data updated in the Application's update method. Isn't it?
In this manner the program works with 2 separated thread, one for grafics and physics and the other dealing with the network. Right?
So, in theory, there will be any delay in the rendering loop caused by the client process of sending datas. Or will there be?
Or is better to create a completly separated "exchanging thread" which is in charge of sending and receiving data to/from the server in an asynchronous mode respect to the graphic thread?
Thanks
That is what I am doing. Client updates his position / stats on a separate thread that is not synchronized with the main game loop. Some of my reasons for using a separate outside thread is
1. you will not always be connected or need to send data on every drawn frame. For example you load up your game and its a login screen or opening menu, if the network code was in your render loop you would have to have a conditional inside the render loop to know when you are connected and to start sending data.
2. The render loop eventually is bottlenecked at the number of frames a person can run on their machine. I'm sure you have seen games where someone has 200-1000 ping and is hard to hit etc. (The problem I just described is not because they have their networkcode in the game loop but I am just giving an example of frustrating game play). So now if you did put your network code inside of your game loop and you are rendering frames at lets say 120 frames per second and player 2 is rendering them at 20 frames per second. Effectively you have updated your position to the server 60 more times than player 2.
The point I'm trying to make is you need to account for other people's system and try to make it a fair tradeoff or else you will run into weird looking problems. I'm sure you "could" put your networking code in the loop but as of right now I don't see very many positive reasons to do so.
I posted exactly because I was worried about sync. I share your views.
Now, in pseudo-code:
[java]Main {
void main {
new NetThread
new GraphicApp
}
}
GraphicApp extends Application {
@override
update() {
/* 1. get info from data stored in the NetThread /
/ 2. state/render updates associated with tpf*/
/* 3. write changes onto data memorized in the NetThread object /
}
}
NetThread implements Runnable {
data
@override
run() {
/ 1. always listen from server*/
/* 2. store information into data /
/ 3. at a given time [differente from tpf], send data to server
}
}[/java]
Could it work?
You dont necessarily have to listen from server on an entire new thread if you are using spidermonkey. When you register a listener to the client, the client connection is already on separate thread. So if you register a message listener for your client inside of the main application (where your reference to the spidermonkey client is) and listen for message received and then parse out those messages to do they are intended to do, you should be fine there.
You are worried about synchronization, well what really matters is
- Can you get all different types of clients sending updates to the server within the same range (meaning on the same hertz frequency)
- Do you have a server that sends updates to its clients on the same frequency?
The answer to 1, is to have your clientUpdateThread for the network only run at certain frequency (like I explained in previous posts) and if it goes faster, sleep the thread till it is at the appropriate frequency.
The answer to 2 is similar to 1 but that depends on your approach. You could respond to the client every time the server gets a message from him, but in my opinion you can’t guarantee synchronized updates. I did the same thing for the server as I answered in number 1, basically force the server to only run at X amount of hertz.
The answer to 2 is similar to 1 but that depends on your approach. You could respond to the client every time the server gets a message from him, but in my opinion you can’t guarantee synchronized updates. I did the same thing for the server as I answered in number 1, basically force the server to only run at X amount of hertz.
So, at a given time, your server sends each single status to each client each using broadcastExcept? Isn't it a bottleneck at every given step and this situation could waste time between each update?
My implementation, for now is a server which responds immediatly [or nearly] to each update sent by a client, with a forwarding at each other client.
I know this method lacks of synch [maybe a damage for checking for killing], but I thought this could gain velocity.
cardoppler said:
So, at a given time, your server sends each single status to each client each using broadcastExcept? Isn't it a bottleneck at every given step and this situation could waste time between each update?
My implementation, for now is a server which responds immediatly [or nearly] to each update sent by a client, with a forwarding at each other client.
I know this method lacks of synch [maybe a damage for checking for killing], but I thought this could gain velocity.
Remember I am not using spider monkey, I have written my own networking piece. But essentially yes I am sending the update to all connected clients. I'm not sure what you mean by steps, but my server which sends the updates runs at certain hertz on every iteration of that hertz it sends to all connected clients. I'm not understanding where you think a bottle neck would occur.
As I understand it , your server when it receives a message from the client immediately responds with the servers state. This seems like it will cause issues with your sync mainly because of lag. This also depends on whether you are using TCP or UDP but lets just assume the following. If client A is connected to the server and it takes 60 ms to send to server and 60 ms back, that is 120 ms before the client will get an update. If client B takes 20 ms to server and 25 back that is 45 ms before he gets an update. Depending on your game, Client B has a 75 MS advantage.
Using my approach if the server is sending out an update lets say every 40 ms (0.04 seconds) and it still takes 60 ms to reach client A. Client B is also receiving updates from the server at 40 ms but it takes 25 ms to reach him. 60 ms - 25 ms = 35 ms is now the difference between the client A and client B when dealing with the server. The other major difference is now client A and B are guaranteed to see a new update ever 40 ms + time to travel from server instead of Time to travel to server + time to travel from server.
Again my methods could be very flawed but as you can see from my explanation there are some reasons why I am doing it this way. It depends on your game, what kind of game are you making? I can get a better feel and maybe point you in the right direction if I know more information.
If you are making a FPS or any real time game where players movements need to be accurate you will have to take a similar approach as mine. If you are making a strategy game like chess your approach will work. For chess you don't need to constantly send states, only when a player makes a move which can be event based on the server.
Here my first try:
http://www.youtube.com/watch?v=6UhjvD_qUdY
– edit by normen: need a line after youtube link, bug in forum
1 Like
Looks great 
Nice job!! Hopefully all my rambling was helpful 
Nice job!! Hopefully all my rambling was helpful
Of course! This video shows only the basic things for connection: One pc running the server and one client and another pc running only the client. Poor graphics [no animation, no sounds, no background]. Keyboard controls ok.
Now I want to implement some kind of "movement prediction/interpolation/lag compensation" to reduce the lag and the shaking.
And I have to make the server more clever, because I think is better if it can determines player's deads.
Got any ideas?!
Interpolating will be your best bet and probably the easiest. I did it on the client side when I get a movement message from the server. I interpolate between previous position and current position. This smooths out the choppiness because your server is updating the player and just moving him to that location over and over. Interpolating basically “blends” that movement together.
To make your server “smarter” you should already be keeping a state of every connected client. Meaning their position, rotation, direction, health, etc… So all you have to do is send a message to the server saying the client has died. Or depending on your game, your client sends a message with an action like Shoot, server interprets who got hit and who lost health and sets the state on the server to DEAD and rebroadcasts it out.
To make your server “smarter” you should already be keeping a state of every connected client. Meaning their position, rotation, direction, health, etc..
Yes, my server holds a world status, which in effect it updates each time he gets a messages from a client. Client only displays the positions sent by the server. I'll look for interpolation.
So all you have to do is send a message to the server saying the client has died.
Thinking about cheating, I suppose it will be better to have a server who can look about deads, shoot and so on, instead of rely this on the client side. But it raises a question: Between two updates, a client can shoot many times. I think it's not possible to send a "shot message" each time he pulls the trigger. So, which is the best manner to do that? Pass an array holding a direction for each bullet shot? SO the server can rebuild the scene like CSI and determines who has to die?
"If client X shoots at time Y in direction Z, client W [which is in position P, at the same time Y] must die"
?