I'm trying to create a desktop app with RMI (Java) for school. It's a simple chat app and I found plenty of examples about creating a chat app with RMI.
The "problem" is that I have to make this app fault tollerant, so my professor asked me to create also a peer-to-peer connection between clients if the server doesn't work.
So I have to create two types of connections: client/server and peer-to-peer.
I have two questions:
1) Which is the best way to save the data in the local client side in order to access them if the server doesn't work?
2)Can I create peer-to-peer connection with sockets or there is another way on doing this?
Thank you very much.
1.You should detect a remote exception error or server is when unreacehable using
try {
}
catch(RemoteException ex){
//do some peer - to -peer look up here or other way
}
in your client code which tries to connect to server and when accessing a STUB on RMI. Second , you need a central server location that Peer-TO-Peer data exchange is possible.AT least when every peers comes in to connecting to the central server(RMI server) or want to chat additionally it needs to record some information about him self in some other shared data repository.This not the best answer but ,just an ice breaker.
2.Sockets and Yes sockets are pretty enough for peer-to-peer connection!!
Related
I want to develop network application (servers-clients) with some process:
server creating instance on specific port and sending to other client in network information about existance (can be invitation message);
clients are checking about existing servers in LAN network on specific port. Choose which one to connect and do other actions.
I tried ServerSocket and Socket and I know how to connect one server to one client. But to do procedures described above I need to do something like broadcating. Which method should I use and try? Is MulticastServer good for that one?
Thanks for help.
I am planing to develop JavaScript client application that will connect to Java server using websocket. Server should handle many connected clients.
After some reading I found out websocket single thread. This is not good if I want to run databases query that can block everything for a while.
What I am thinking about is to opening separated websocket for each JavaScript client. One socket is listening for new connection and when connection is established creates some unique id. After that opens new websocket and send id to client using listener socket. When client received id close first socket and connect to new one.
What do you think, is it good solution? Maybe I am missing something?
Spring 4 gives you the chance to use a thread pool. The documentation is here:
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html
You could use Akka to manage all the concurrency and thread management for you. Or you could use the Play Framework that already builds on Akka and that supports WebSocket quite nicely. With Play you can choose between Java and Scala on the server side.
You should use NodeJS on the server to handle the socket i/o. You can connect to it via your javascript client apps, and then make calls to your Java based API. NodeJS is non blocking (async) and you should be able to leverage your existing Javascripting skills to quickly build a Node app. You could even use a full MEAN stack to build the client/server app. http://meanjs.org/ or http://mean.io/#!/ are two popular places to start.
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
We are using Openfire (Jabber) to enable chat and presence capabilities to our MMORPG. In our server architecture clients only open a single connection with the game server, and upon login, the game server creates a new connection to Jabber for this new client.
The problem is, we don't want to open a new connection to Jabber for every client that logs in, we like it better if our game server acted as a connection manager and talked to the Jabber server through a single connection, yet being able to manage hundreds of thousands of 'logical' clients.
Is this possible?
Any links or info on this matter would be very much appreciated. Thanks.
Why not have a local Jabber server separate from your game server, but on the same network and let it handle all the messy details?
If you have a massive game, you will most likely also need massive network.
There is already a connection manager for Openfire, open-sourced (though it does need an external library as well that is not OSS). It connects to the clients and from there talks to the main server as a jabber component. It sounds like you want to be able to do a similar thing with your own system.