I am currently following an article about a simple gameloop, I can get my game going locally and I can add a lot of objects and behavior into it.
The article is this: http://www3.ntu.edu.sg/home/ehchua/programming/java/J8d_Game_Framework.html
My game is a grid, where other players can change some simple rectangles. It doesn't need to be the fastest approach, but somehow I need a new thread that connects to my server, and modifies the gamestate, which will get drawn on the screen. I just can't see how I can implement it, without causing the applet-thread to hang.
Can somebody see a solution to this?
Are you having a threading problem, or are you asking how to design the communication between the server and client?
For the communication problem, here's a simple approach: have the server periodically send each player updates, whether through a constantly connected TCP connection or just periodic plain old unreliable UDP packets. The choice of which one to use will depend on your application requirements. Read about the difference between TCP and UDP -- there are many, many places,including on SO (just search), that discuss the tradeoffs. Once you have the server updating on state and you can verify this works by giving the server some scripted state to follow, you can send some data the other way too. Depending on your application, you may need to be careful about security: whether a player can lie to the server about its actions, etc.
In Java, connections are often done through the Socket and ServerSocket classes, or through the DatagramPacket and DatagramSocket classes.
I just can't see how I can implement it, without causing the applet-thread to hang.
Implement an ActionListener to do the server update/check. Call the listener in a loop using a Swing Timer. See How to Use Swing Timers for more details.
Related
I'm trying to simulate flow control and congestion control in java. I have a simple code with a TCP-Client and TCP-Server, but I need to separate it into two parts: Flow Control and Congestion control. Then, I need to capture TCP packets in WireShark to see what is the congestion window behaviour.
I have been reading about it, but I haven't found anything about this topic. Would someone give me an idea to start with this?
I have read Networking from Kurosse, but it just give an illustrative example on how TCP works.
I came across this project from a professor at Rutgers, The State University of New Jersey. Along with the source code, it also contains a design document on how to design a TCP Protocol Simulator that also details congestion control.
The relevant snippet from the design document that might help you would be
Our default “network” consists of a single router (Figure 4). This model is based on certain assumptions about TCP operation. Our focus is on studying TCP congestion control and not other aspects of data networks. For this purpose, it suffices to abstract the whole network as a single “bottleneck” router.
Reference - Page 10, Section 1.3 - https://www.ece.rutgers.edu/~marsic/books/CN/projects/tcp/tcp-sim_doc.pdf
So I am making a program that will only run one instance at a time and am doing so by using this solution
However now I would like to make it so that if the user trys to launch another instance it will consume that attempt and notify the current instance to show its gui.
Currently I am thinking about doing this by the use of a file. Upon the launching of a second instance, a file called show.stage will be created. When the other instance detects that file it will show its gui and delete the file.
I know this works but I was wondering if there was a more graceful way to do this.
Could I some how set a environment flag that the other instance could check for or maybe notify it via a socket listener, although those seem to be discouraged by others. I get the feeling creating the file will be the easiest and most robust way but I am open to any suggestions
This program will be running on normal windows.
If you don't want to use a lock file (which I think is a perfectly good solution), you can use sockets.
Have your application create a socket server and listen at some port in localhost. If it fails to listen, it would mean that someone else is listening to that port already - most likely, another instance of your app. You can even connect to that port and send messages to notify the primary instance that a second instance tried to be spawned.
The caveat is that if another app legitimately uses that port your app would never be able to run - but I find that very unlikely to happen.
There are many ways to go about this:
as you already figured, the file system can be used as communication channel between two jvms. But that only works for jvms running on the same server.
thus the already suggested socket solution enables you to (later) apply the same solution to a distributed environment. The downside is that you have to implement a protocol on a very low level.
in the past, people often turned to message bus solutions (think ActiveMQ for example)
in 2018, the other alternative would be to implement a simple restful API, using jaxrs and jersey for example.
As said: the effort you want to put into this depends on your requirements. How long will it be used? What are the odds that your solution will grow and has to scale to more than one server?!
try to use pidfile as lock and process single like kill 9 as communication tool
I'm implementing a multiplayer option for a chess game I made, but I'm starting from zero to do both client and server. A friend said to me to make the game happen in the server, and the client only gets the data and shows in the GUI. Does this means that I have to implement the game in the server (without GUI); and in the client project, just the GUI, actionListeners and stuff, so that, for example, when I click on a piece and then click where I want it to go, the server will "make" the move (set new position etc) and then send this information back to the client so that it can print? Is this the best approach?
By the way, my server can (will) host several games (each time 2 sockets connect it creates a game thread). Oh and also, after finishing the game, I want to implement a little chat in-game. Don't know if this information changes something...
Longer answer is that you really have a lot of flexibility in how you want to do this. The "traditional" way of doing this is the model-view-controller pattern, where you separate the model (game state) from the view (what the board looks like), and a controller (your server code) handles interaction between the two.
The question is where to place each section of code.
One option is to place have the client do the heavy lifting with the server acting as a middleman between clients and communicating updates. This has the advantage that servers don't need to do as much work, but results in a client that can be easily modified for cheating.
The other option is to place most of the important code on the server and simply have each client be a "dummy" display that just shows whatever the server sends and just send the bare minimum amount of information to the server for the server to determine what was done. This is more hackproof, but places greater load on the server.
You can also do a hybrid model where the both the client and the server share the load of sanity checking, so the load on either isn't quite as severe. I think that this is a pretty good option, even though it violates the "pure" MVC pattern.
What works "best" for you might depend on the kind of load you expect on your server. For a small number of connections, "pure" MVC with "dumb" clients might work. Client makes move, server verifies that the move is valid, and if so, sends updates to both clients. If your framework starts to get overwhelmed you might want to consider putting some checking code in the client though.
None of this affects having multiple pairs of clients or a chat. You should be able to implement each of those parts separately, and if done correctly piecing the modules together shouldn't be bad.
I'm having two main code design problems in my app.
My app mainly consists in sending ssh commands to a remote host.
Right now I have a separated thread (singleton) which gets messages through the handler which specifies which is the next command to be sent, or the username/password/ip (kind of messy but works...).
This approach works good for unidirectional commands, but I'm planning to make it bidirectional which I don't know how to implement. As far as I know Android doesn't allow to change UI elements by another thread so a listener pattern wouldn't be it.
Also, I just read that we shouldn't save things in the application object, which is also what I'm doing by saving whether my app is running full or lite mode... I don't know where should I save it in order to not make it obviously hackable (sqlite-SharedPrefs are easily editable...)
Only a general hint: There is Activity.runOnUiThread() to execute code (later) on main thread.
I have a master program, and a client program. Whats the best way in Java to connect these two programs so they are synchronized, where if one change on one program happens then the change happens on the other?. The programs are identical but the GUI is different one for a mobile device and the other for a computer.
I have tried looking on the internet but have just been baffled. If anyone can point me in the right direction that would be great.
Thanks.
Make a server with some web services. Then all your programs will be communicating with the server. You don't have to write something twice - you just change the UI layer and than you can it easily run it everywhere.
You solution has a big flaw - if you liked to add one more device (other mobile platform), the coding would be enormous and too difficult.