im developing a multi-player card game that needs the clients to communicate with each other or a general server. i have never done this before so i need some direction or tutorial on how to achieve this.
so far i have created the local, single person version of the game...
Sun has a good tutorial on writing a client/server pair complete with code examples.
So far i have created the local, single person version of the game...
Great, I would suggest to continue with the local multi-player version of the game ( even when it is controlled by the same "terminal" )
From there you may explore RMI to invoke the methods remotely. It should be much more simpler than creating the multi-player version and add networking.
What RMI does is to abstract the network connectivity and allow you to simplify the execution of remote objects call ( that is, it simplifies having to write your own protocol with sockets )
RMI is more complex. You need to understand some concepts before starting with RMI, like extending Remote, RemoteExceptions, etc. And also, running applications powered by RMI require some steps, such as starting rmiregistry, and setting a policies file.
If you are a beginner, start with simple sockets first. They are easier to understand, but somewhat long to code. RMI is easier to code, but somewhat tough to understand.
For Sockets:
TCP Sockets
UDP and Datagrams
For RMI:
Simple tutorial to RMI - Really helped me start
Related
Why does Java RMI exist? Who uses it and for what?
My most pressing questions;
Why would you want to make calls to methods that aren't defined on your machine? Wouldn't it take much longer to execute? I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides? In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer, then doesn't it get annoying to have manually contact eachother to update the interfaces on both sides for each little change?
How is this similar or different to a typical web app set up where a client communicates with a server? In my mind, HTTP calls are much easier to understand. Can an RMI Server require some sort of password from RMI clients?
What kind of applications are typically made using Java RMI? Any hard examples?
Why does Java RMI exist?
Err, because Sun built it? The same Sun that provided Sun RPC.
Who uses it and for what?
RMI is the basis of Jakarta EE (formerly J2EE) just to name one small example. However the concept of remote method calls dates further back to at least CORBA, and the concept of remote procedure calls to at least the 1970s. Sun provided their implementation of RPC in about 1982 and it is the basis of NFS among other things.
Why would you want to make calls to methods that aren't defined on your machine?
Err, if you wanted them to run on another machine?
Wouldn't it take much longer to execute?
Of course.
I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
So you've never heard of distributed computing, then?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides?
No.
In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer
Did somebody say that was a benefit?
then doesn't it get annoying to have manually contact each other to update the interfaces on both sides for each little change?
There don't tend to be many 'little changes', if you actually design your system before implementing it. But that isn't the only development model anyway. You could have a third person developing the interface. Or the same person developing both sides. Or have the remote interface defined by a specification. Or ...
How is this similar or different to a typical web app set up where a client communicates with a server?
It uses RMI instead of HTTP.
In my mind, HTTP calls are much easier to understand.
You can't get much easier to understand than a remote interface, but obviously your mileage varies.
Can an RMI Server require some sort of password from RMI clients?
Yes, it can use mutually-authenticated TLS for example, or arbitrary authentication protocols implemented via custom socket factories.
I have a C++/Qt application. I want to talk to it using Java.
I know I can create TCP server/client. What other options do I have?
The problem is that I created TCP server inside the application and it does not work. But works fine when run in standalone mode. So looking for alternatives ways of communication between C++ and Java.
I have a C++/Qt application. I want to talk to it using Java. I know I
can create TCP server/client. What other options do I have?
Basically, what you are looking for is IPC that is supported by both languages properly. You can find several solutions out there:
Java and C++ socket communication.. Obviously, QtNetwork and the socket classes in there could be your friend for this on the Qt side.
http://www.velocityreviews.com/forums/t279534-communication-between-a-c-and-java-program.html
Java Native Interface. You would be able to call C/C++ methods from Java and vice versa, although this would be probably one of the slowest solutions.
Shared Memory (SHM) (Here, QSharedMemory could aid you on the Qt side).
Google Protocol Buffer
Dbus (Here, QtDbus could aid you on the Qt side). This is not necessarily cross-platform a solution, however.
I would personally suggest to use raw socket based low-level solution with the Qt API. This is the most reliable in my opinion, and well-proven technology behind. There is Qt Jambi with Qt style API for the java side, and then of course in C++, you will get the QtNetwork API. This would at least provide you some consistency throughout the projects.
I have a game called wizard wars that I have been working on. This game needs to allow 2 players to play at one time, and would need a TCP connection to communicate spell creation/destruction ect., and a UDP connection to handle locations ect. It would have a client and a host side. That being said my program is designed to run on Android. All of the tutorials/information I have found online has been for JApplets or something like that. So what I would like is some help with ever short code examples of how to set up/use connections, or just a link to some sufficiently helpfull information on how to set up the actual connections.
The best approach (or at least 1 approach) would be to use normal HTTP requests : http://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/Net.html
You create a webservice implementing REST and create calls for both updating and consuming data.
Alternatively, if you're just going to use Android and Desktop you may also use WebSockets : https://github.com/pepedeab/libGDX-Net
For those who don't read comments, but still looking for tcp client.
You can use KryoNet which supports Desktop and Android
https://github.com/EsotericSoftware/kryonet
Have you guys looked at the multiplayer super jumper tutorial? Its written using AppWarp and is being actively used in the libgdx community as well.
I want to create http socket connection for server in php for multiple client . how can I do that ? I need some resource .
First I was trying to create server in java .I create a server in java . And trying to reach from android application .But server can't find any client.But when I create client in java .It was working. How can I solve that problem ???
Take a look at this article:
Writing Socket Servers in PHP by Zend
Also give a try with Google:
http://www.google.com/search?aq=0&oq=php+socket+server+mul&sourceid=chrome&ie=UTF-8&q=php+socket+server+multiple+clients
Personally I think this would be a pretty bad idea, as already mentioned it lacks Threading and it's Socket support (imo) isn't really that adaptable.
The only plus side is that you can use fork to fork off another PHP process to handle a client, but you're getting very complex.
Another language would be much more suited for this type of development.
Note that even if you did do this in PHP, you'd probably have to rely on external services anyway, and possibly even end up writing at least some code in another language anyway.
You're trying to use PHP to do what? Mind you, I like PHP and work with it almost every day, but please do remember PHP in and on itself is based on request and response, and not very suitable for long running processes. In a manner of exercise, it might be interesting, but if you're trying to write a webserver from scratch using PHP, you might want to reconsider your choice of language.
That said, you can create a socket acting as a server, and listen to incoming packets. I do still think you're reinventing the wheel though.
though i love php and java, i wrote my socket servers in c++ running under lamp in an amazon ec2 cloud server. it is very, very simple to code and debug and safe and you can practically just copy/paste examples.
in the long run, i will probably develop a java solution because of portability and scalability, but the initial effort to get a c++ solution working is just so much less than implementing a java solution...
the first thing you must ascertain (find out) is whether your server allows you to open custom ports. amazon ec2 does and at this point in time (feb13), can be used for free for 12 months.
so, this is for you if you are in a hurry:
this here set of examples has all that you need to be up and running in no time.
Judging from the question title (the rest only makes it more confusing) you could use an existing package like http://pear.php.net/package/HTTP_Server to implement a webserver in PHP. It already contains all the socket code to accept client connections and stuff.
So what i have to do to find the server from different client
"Finding" is too broad a topic. Depends on your actual setting. On a LAN there are some protocols for discoverability. Otherwise you should just rely on a fixed machine name and port number for your instantiated server. You can connect to it as e.g. http://localhost:8007/ or whatever you've predefined.
We're come across a problem here at my company and I'm trying to find the best solution.
Software was recently purchased that utilizes a Java program to get the tax for a certain shipment. The site that needs this was written in PHP4. How can I communicate between the two?
It was suggested to use files to communicate but that was horribly slow since the Java program needed to be recompiled every time. So, what is the best solutions to this:
Create a mutli-threaded Java server and use PHP to send/receive the info.
Some other type of file-writing method
Something cool that I dont even know about.
Thanks in advance!
Edit:
I understand the importance of web services but why would this be more efficient that using a mutli-threaded socket-based java server? The only thing connecting to this web services will be my PHP program, no one else. It seems like it might be overkill for my simple task. Am I mistaken? If so, why? Thanks.
Wrap the Java program in a Web Service, and invoke it from PHP. You can even use caching in the Web Service, to optimize performance.
Why not dump the info into a database and have some sort of schedualed job read from it once and a while?
You can always use Quercus which allows you to run PHP in a Tomcat Servlet container.
Web Services is the elegant solution. But in many cases I found much practical to go for a quick-and-dirty solution: start a Java server that communicates using a lightweight communication protocol (none of the heavyweight stuff like XML from Web Services) - example: Apache Thrift. The write a very light client, that takes parameters from command line and writes the output to the console. The client can be in Java or even in other languages, like C++ (Apache Thrift supports that). Then you call the client with system() or with exec() from PHP.
This is not a solution I would ever recommend for production, but it's great for prototyping. Quick and dirty and flexible and extremely modest learning curve (if you already use light-weight communication between your Java processes).
Since you are using PHP4, you may want to just set up a tomcat server that is on a closed network, or just local on the machine of interest, and have it communicate with a servlet, that way you don't have to write a multi-threaded server and deal with creating a communication interface.
If you can upgrade, this page has two other options that may of interest:
http://us3.php.net/manual/en/intro.java.php
Give a look at Quercus
Quercus is Caucho Technology's fast, open-source, 100% Java implementation of the PHP language
I never used it though,
Web Services is the answer. Here's a nice intro link. Your problem is the very reason web services came to the forefront - communication between systems that couldn't ordinarily communicate.
What a web service is essentially going to do is send XML between the PHP and the Java systems. You're going to have to establish an interface for the two, which might be more difficult at the upstart, but you'll reap the benefits later on. In either case, it will be much faster than reading and writing files on the server. Disk I/O are the major bottlenecks on any server.
I may miss something, but if your java program output the needed values, can't you just start the java program from php using exec (http://dk.php.net/manual/en/function.exec.php)
Use the PHP/Java Bridge from sourceforge.net. It is mature, fast and easy to install.