Considering application_A on a machine_1 needs information about machine_2, provided by application_B (which is located on machine_2) and that both machines are in the same network, what would you guys suggest to be the easiest way of implementing the communication between the 2? (I was thinking simple socket connection).
Note: the information required is something in the lines of a few bytes, so nothing big.
You can either use socket based communication or Java RMI.
I would recommend Java RMI as its easier and saves you from handling raw socket communication.
If you are familiar with Spring framework, then writing RMI application in spring is very easy. Check Exposing services using RMI (Heading 17.2)
There are different ways to implement this but they all come down to one thing: communication over sockets.
If the information is only some bytes, implementing the sockets themselves is probably your best bet, if things start to get bigger, you might want to look into some middleware.
You can run a server program on Machine2 using ServerSocket and a client program in Machine1 can request for info.
You can try web services. JAX-RS would be the simplest.
Related
I am trying out a simple socket programming example. I was able to run a server application and client application to communicate with each other. I now need to know a tutorial that explains how 2 clients could communicate with each other through the server.
How can I do this ? Can someone point me to a good tutorial or an explanation on how this can be done in Java
It's not that different and difficult than writing client/server pair. You just have to create threads on server just there, where you accept connections from clients. If your clients should communicate each other, than you surely need a list to store them. And you have to implement, what your server does (communication) in this thread.Here is a good chat programm tutorial: http://www.dreamincode.net/forums/topic/259777-a-simple-chat-program-with-clientserver-gui-optional/
I want to build a chat application and am confused about deciding whether to use sockets or RMI to build the application. I have heard that RMI is difficult to configure and deploy over the Internet, since that is my intention I was wondering what would be more appropriate to go with, sockets or RMI. Also is it easier to solve issues because of NAT in sockets or RMI ?
What if I want to add voice support at some later point, does it help deciding which way to go ?
1. For applications like Chat Messenger, my bet will be on Sockets.
2. RMI will be an over kill here.
3. Moreover NAT issue is not about Socket or RMI, its about Static IPs.
4. If you want to deploy a Chat Server over the net, then first you must have a Static IP, you need to have to ask your ISP to provide you with one of them at extra cost, or there are sites over internet, that makes your dynamic ips as static.
5. But if your server is locally located in a LAN environment, then i think you won't have a problem in doing it.
Both are reasonable choices that could be used to build a chat server/client. A socket can be set up to take incoming connections and start a new thread for each "chatter" alternatively RMI can be used to create a distributed object on which the client can call methods.
RMI is basically a layer over sockets often used in distributed computing where some transparency is needed and remote methods need to be called. It also allows for stateless connections to the server.
If you choose to implement the server in RMI just be warned that thread safety may be an issue.
For a local server it is probably easier to use pure sockets.
For more details on RMI:
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html
I have not worked with HTTP post/get before, my up coming project in my office is based on http post/get in java. Its basically client - server based application. the client will post some info and I need to get that info and process the string and vice-verse. this project has to be developed on J2SE. You can assume this some thing like a JMS queue message processing stuff. I googled for the info but most of the information was for web application, mine should work like a message queue. Can someone explain me how to do this or point me where I can get some useful info.
Thanks
Arun
Well, if you don't need to specifically use strict HTTP, and you need to just use Java SE (and not Java EE, which rules out Servlets, JSPs, JMS, etc), then you need to probably investigate ServerSocket and Socket classes.
Server
Your server would need to listen on a TCP port (say, port 8080) - usually you would pick a port number between 1025 and 65,535, however if you are attempting to use an already defined service that has a default port, then use that. Note however, that on unix, in order to listen on any port below 1024, I believe you need to be root. Traditionally, port 80 is used for HTTP.
To listen on this port, you would need something like this in your code:
ServerSocket srvSocket = new ServerSocket(8080);
Socket socket = srvSocket.accept();
This pretty much the most basic code that would cause your application to wait until something connected to port 8080. Once connected, you could obtain both an InputStream and OutputStream for your connected client, by interrogating the returned socket object, allowing you to read content from the client, and inserting these requests in a queue. This queue could be then processed by some other Thread.
Client
In order for your client to connect to the server, you would need to use something based on the following example:
Socket connection = new Socket("server.domain.com", 8080);
OutputStream output = connection.getOutputStream();
You would then write your request to the server into the OutputStream (and read from the InputStream returned from getInputStream() if you expected a response)
The code supplied is pretty basic, but it should give you a rough idea of how to proceed. You can even use this method if you wanted to use real HTTP, however it might be a better idea to use some premade library if that was the case (although its probable that you're not going to require all functionality defined in the HTTP spec itself).
Anyway, I hope that provides you a good starting point from which to build.
Jetty is a popular web server, designed to easily be embedded in an application.
Its HTTP server component can run inside your application and respond to requests by dispatching to your custom code.
Jetty also features an HTTP client that you can use on the client side to send requests.
This is a rather big topic and I won't be able to post a complete guide, but Jetty's documentation is generally of very high quality and should be a good starting point.
I suggest you start with learning the basics of HTTP protocol. This article is a good starter. After you understood the basics follow the this article on how to programatically communicate (read/write) with HTTP servers. After that Google is your friend.
If you weren't restricted to J2SE, you could use Servlets for managing the POST/GET methods of HTTP. Evaluate if it is possible, otherwise you'd be reinventing the wheel
I also have a mainly SE background. On the client side, writing get/post is pretty easy. Or you can Google to find source code. I found that using REST was straightforward and understandable. On the server side, there are many options and I have very limited experience. I wrote the server using standard JEE6 and it wasn't too painful, but sounds like that is not an option for you.
I'm writing a multiplayer/multiroom game (Hearts) in java, using RMI and a centralized server.
But there's a problem: RMI Callbacks will not work beacause clients are Natted and Firewalled. I basically need the server to push data updates to clients, possibly without using polling and without using sockets (I would code at an higher level)
In your opinion, what's the best solution for realizing this kind of architecture? Is an ajax application the only solution?
You say that you don't want polling, but AJAX is exactly that. You can look at Comet but it's hard to escape polling anyway (e.g. Comet itself uses polling underneath).
You could use a peer to peer framework such as JXTA.
I can suggest two main techniques.
The server has a method getUpdates, callable by clients. The method returns the control to the client when there is an update to show.
When Clients perform the registration, they give the server a callback remote object
Since this object is not registered in any rmi registry, there should no be any issue with natted clients.
I'm not sure how(if) ajax works for a non-browser-based app. You could just maintain your own pool of SocketConnections open for the duration of the application with a Thread per connection.
If you need to scale to a lot of concurrent connections, look to a non-blocking I/O framework like Apache Mina or Netty (related SO post: Netty vs Apache MINA).
well, i am developing a single server multiple-client program in java. My problem is can i use single stream for all the clients or do i have to create a seperate stream for each client?
please help
thank you
Typically you'd need a stream per client. In some cases you can get away with UDP and multicasting, but it doesn't sound like a great idea for a chat server.
Usually it's easy to get a stream per client with no extra work, because each client will connect to the server anyway, and a stream can easily be set up over that connection.
Yes, you can but I think it would be harder.
If you're using java.net.ServerSocket then each client accepted through:
Socket client = server.accept();
Will have it's own stream so you don't have to do anything else.
Is there a real need for a single stream for all clients or is just something you think it would help.
For the later it could cause more problems than those is solve.
Can you do it?
Yes, as Jon Skeet said, you can use multicasting.
Should you do it?
That depends on what you are using the streams for.
For most client server applications, you will need a stream per client to maintain independent communications. Of course, there are applications where using multicasting is the right approach, such as live video streaming. In such a case, you would not want to overwhelm your network while streaming the same data to multiple clients. Of course, even in this case there will typically be a single control channel of some sort between each client and server.