I know my IP address, and that of my friend.
How can I transfer objects/files between the two machines?
I am an advanced Java programmer, but have never worked with networks before.
EDIT:
I am now using an API called jnmp2p ( http://code.google.com/p/jnmp2p/ ).
It works fine when I use internal IPs, but fails when I give the external ones.
How do I connect to a computer that isn't on my private network?
If you looking for communication between two java applications and do not want to meddle with the low level networking details, then you can use following two approaches, depending on the type of applications you are dealing with.
If both the application (on two machines) are java standalone applications, then RMI is the best bet. Check out the basics from these links (1,2)
If your application (receiving files/objects) is a web application then its you can write the Servlet on the serve side and then write a client application to send files/objects(binary) to server. Commons FileUpload is very popular library for this purpose.
Author of jnmp2p here. I don't maintain the library any more because I've moved onto other things. However I had some comments.
Peer to peer communication with IPs outside your private network is a hard problem. This is because stateful NATs and firewalls on both ends have become common-place, which prevent you from establishing connections between machines directly.
For example skype uses a rendezvous service where both machines start outbound connections to a third machine and communicate via that. Aside from setting up additional infrastructure that any peer to peer solution is going to be limited to subnets within your NAT, so solutions like JNMP2P or RMI (with gross modifications) are going to be your best bet.
Related
For the past few weeks, I have been scouring the internet, the minds of computer programmers, and just a few random people over the situation I am looking to overcome. Basically, what I am trying to do it write a AntiJoinBot "plugin" (if you will) for the popular game Minecraft. This would be like all others in respect that it blocks IPs based on if they are using a proxy or not, but this AntiJoinBot is running on a different VPS than the actual server.
This is the best graph I can make of the situation (it's not that good):
(non-minecraft server) Connection -> Proxy check -> Redirect to the
server -> Minecraft
The only problem is, I need to be able to redirect the IP and close the connection so that the player's real IP is the one that would connect to the server. If the connection is not able to be closed, it would cause real problems due to some of the plugins we are running.
If you have a solution or a better way to do this, please help me.
Redirection of connections along the lines that you want requires support from the (application) protocol. TCP/IP does not support it. AFAIK, SOCKS does not support it either. Unless the Minecraft application protocol (and by implication, Minecraft clients and servers) include support for redirection, you are out of luck.
(FWIW - that's how HTTP redirection works. HTTP has a "protocol element" that allows the server to tell the client to redirect, and where to redirect to. The client then resends the original request to a new address.)
But that doesn't mean that you can't deal with the pests. It just means that the redirection approach is not viable. Try a custom proxy or an IP filter / redirector instead.
You are trying to save the server's resources on the cost of increase Traffic.
I am not sure with the answer but may be by looking into the concept of LBS(Load Balancing Server) you may find the answer.
LBS is purely defined and controlled by us so you can manage the resources of two servers using one load balancing server.
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 would like to have the clients query each other through the server without delay ( = no polling interval ).
Example: Server S, clients A and B
Client A wants to request Client B.
Client A will make a request to the server S, no problem there.
Then Server S needs to be able to request Client B but how to do that without polling?
All the node.js/APE (for PHP) technos are designed for the web, however I don't use a web server for that. Does Java has something close to a push technology/framework that is not web?
I would really prefer a solution that doesn't require each client to use their own reserved port (I don't want to end up with 1 WebService per client for example)
Note: all the clients are on the same machine.
A couple of options...
Plain socket communication. java.net.Socket, java.net.ServerSocket. Maximum flexibility but requires knowledge of low level TCP/IP API/concepts.
The good old RMI. Java based RPC layer on top of TCP/IP. Works good when client and server are both in Java and generally in same subnet. May give problems when client and/or server are natted.
Spring Remoting, it's actually pretty decent.
Bi-Directional Web Services. i.e. clients host their own WSes which the Server calls when it needs to do a callback.
JMS as someone already mentioned.
Distributed Data Structures, Check out http://www.hazelcast.com/
Lots of options to chose from, no need for webserver.
If you really don't want to use a web server then I would check out JMS. That being said, all the cool kids are using web servers these days since the protocols are so ubiquitous.
Your use case requires a messaging protocol. We don't really know the scope of your problem but you already said you want a server to exchange requests between clients, so I would go with an existing solution rather than a roll your own approach.
JMS has been mentioned and is certainly a viable Java based solution, another would be XMPP which is a real time communication protocol commonly used for instant messaging.
It is an open standard that has both server and client support in every major language and platform. This would allow you to have standalone apps, web based ones and apps for mobile devices all being able to communicate with each other. The only potential gotcha for your use case is that it is text based. Since you haven't said what requests you want to pass back and forth, I don't know if this will fit your bill or not.
You can use Smack for client side development in Java and any OS server you want.
I know that RMI is short on making connection outside LAN. I want to know if RMI IIOP can connect server client over internet. Is it possible ? If yes what are the possible solutions?
RMI works fine over the internet, it's TCP-based. I'd use KryoNet as an RMI implementation, personally. It's no-hassle, and extremely speedy. The serialisation mechanism uses Kryo, which is one of the fastest general purpose serialisation libraries. Note that there may be issues with firewalls. However, you could easily have an RMI server that listens on port 80. This would be work fine (unless there is heavy packet snooping, I guess). An RMI server that works over HTTP is interesting too. Mmm.
Yes, but only if the ports are open at the firewall. The advantage to using HTTP instead of RMI is that it can easily be passed through proxy servers.
There's no particular advantage to using IIOP over the native RMI protocol JRMP, as far as Internet-wide usage is concerned.
IIOP does gives you the ability to call your Java objects using non-Java based code, so if you want to support non-Java clients, you'll want to be thinking about IIOP or something more browser / JavaScript friendly like SOAP or XMLRPC.
If you don't need to support non-Java clients, there's not much to recommend IIOP. With IIOP, you lose the distributed garbage collection that JRMP provides, so you'll have to decide when any RMI-published object should no longer be published.
With JRMP, all you have to worry about manually managing are the RMI objects you bind to the RMI registry. All other objects you publish will be automatically garbage collected once all references to them (both local and remote) are dropped. If you use IIOP, you'll manually have to call PortableRemoteObject.unexportObject() when it's time to take them out of use.
I created a game and I want to put it on online. I want to buy a website (I'll probably use goddaddy to buy a domain name and use them as the web host) to use as the server to handle game play. Because I would need a separate server for each game, I would need each game's server to exists on different ports. So this leads to my question, is is possible to access these ports on my future web server? (I wrote the program in Java, so I would assume that I would access the ports from the server side by choosing a port for a ServerSocket, and from the client side by using the IP address from the website and the chosen port for a Socket)
(note: also, I am aware that it may be easier to simply use one port and run the servers on different threads instead, but I am just curious to have my question answered)
thanks a lot,
Ian
Technically it is possible to use different ports, but I don't think that a webhoster like goddaddy will let you run a java process that binds to a special port.
If you mean that you are going to create your own TCP server you obviously can create as many instances of your server and configure them to listen to different ports. But it is year 2011 now. This solution was OK in early 90s.
I'd suggest you to use Restful API that works over HTTP. In this case you can forward calls to server side of each application using URL, e.g.
http://www.lan.com/foo/login?user=u123&password=123456 - log in into application foo
http://www.lan.com/bar/login?user=u123&password=123456 - log in into application bar
In this case you need only one server (the web server) that is listening to socket (port 80).
Your server side implementation could be done using various web techonlogis (php, java, asp.net etc) on your choice.
Yes, that should work. The security manager permits connections to a different port on the same IP address that the applet was loaded from.
You can run a Java server on whatever port you want. Each server will accept incoming requests on one port.
The correct way is simply run on one port and each connection will instantiate a new servlet instance (which happens to run in its own thread) that can then service that request. You usually don't need to run separate ports or worry about concurrency, especially if all the stuff that's shared between connections (e.g. multiple players in one game) is handled through database read/writes.
Your host (GoDaddy) will have to allow you use of those ports, but if they are providing proper hosting (not virtual hosting) and given you your own IP there's no reason why you shouldn't be able to.
Your solution may work theoritically, and I like AlexR's solution. But providers like godaddy doesnt let you run a java server, on ANY port. You will need to find out somebody who does. What I found is the cost goes up from $5/mo to about $20/mo, but you get a much better (read faster) machine. Good wishes, - MS.