I'd like to be able to restrict the ports used by my application to some small-as-possible known set. The application uses Java RMI to communicate with a remote server. The registry is exported on port 1099, which is standard. However, it appears that the port used to export the various remote objects is not always consistent, though it does stay the same across multiple connections over a short period of time. My uneducated guess is there is some sort of caching of the server sockets going on behind the scenes which causes this.
I'd like to be able to ensure that the connection always occurs over a few well-known ports, so that users who install the client application have to open as few ports as possible in their firewall. It seems that I could do this by changing the RMISocketFactory to a custom implementation and override the createServerSocket method to always use a known port. However, this raises a few questions:
How does this affect scalability? It sounds great if I knew only one person would ever connect at a time, but wouldn't it block multiple simultaneous connections?
Is it possible to bind these remote objects on the same port as the registry? My intuition says no, as the port would already be bound by the createRegistry call.
Are there other implications I am ignorant of?
wouldn't it block multiple simultaneous connections?
No.
Is it possible to bind these remote objects on the same port as the registry? My intuition says no, as the port would already be bound by the createRegistry() call.
Yes, as long as you start the registry in the same JVM, via LocateRegistry.createRegistry(), and as long as any server socket factories involved are equal().
Are there other implications I am ignorant of?
There are no implications at all. RMI does port sharing between remote objects with null or equal server socket factories, and TCP does port sharing between multiple connections to the same port.
Related
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'm writing a Java application like AIM where I want a lookup server to help two clients connect to each other with the ServerSocket class. Unfortunately a serversocket needs an open port or it will be blocked by your firewall. Without having the clients manually change their firewall settings is there a way I can either find an open port, open a port (it's okay if it asks for permission) I just don't want every client to manually have to change firewall settings. Thanks!
Creating a ServerSocket is what opens the port on the server end (assuming the port is NOT also blocked on the firewall). On many systems, port numbers <1024 are not blocked by the firewall, and therefore often don't require custom configuration. However, since many ISPs have been more and more stringent with what ports they block within their network, many pieces of software have moved to operating over port 80. Why port 80? It's the port used for HTTP, and therefore pretty much open (at firewalls) 100% of the time for any service that operates on the web.
To answer the question of how to find an open port, port scanners perform this function. Basically all they do is try to establish a connection on a range of ports (say port 1-1024). When a connection is successful (in Java you would see this as a good connection over a Socket), you can consider that port "open". You don't need to exchange any data in order to make the connection, you just need to establish the connection, and then close it.
Also, if there is no server software of any kind running on the server, it won't appear "open", even if it isn't blocked. Without a successful Socket (TCP) connection, you won't know what ports are not blocked by user's firewall.
To reiterate, I'm switching back and forth between two related, but separate concepts. Firewalls can block/open ports, or have port forwarding. That's not the same as a port being "open" for connections on a given machine. In order for a machine to accept connections on a given port, there must be a piece of software listening for a connection on that port, otherwise no connection can be made.
I would suggest to look at a couple of alternative solutions that are less cumbersome - scanning for open ports can take quite some time, can cause panicky reactions from firewalls that feel attacked, and so on. There are a couple of techniques that are in active use and have been developed exactly to solve the problem of servers behind firewalls.
UDP Hole Punching, zero user side configuration needed. Simple explanation on how Skype uses this technique can be found here
UPnP / IGD could be used as an alternative, though less devices support it out of the box nowadays due to security problems.
STUN with a Java implementation of client and serverside called JSTUN
Whatever solution you choose, test it thoroughly with different internet service providers, there's a plethora of limitations you can expect wrt blocked ports.
I'm trying to get a BACNet scanner up on an Seimens server running the Apogee system with a BACNet interface. I've tried using BACNet4j put i get a port bind error on the LocalDevice object for test/Scan.java.
Does anyone know of any other libraries I could use or a reference to instructions for setting up a BACNet plugin to a building management system?
I have had the same problem before, i.e. the BACnet client needs to both send and receive from UDP port 47808. Since the BACnet server already uses that port to listen (and reply) my solution was to use a virtual IP (a bridge) so that my client runs on the same Ethernet card but with a different IP address. A bit convoluted, I know, but it works.
Whether or not the Apogee system supports virtual (or simply additional) network drivers is another question altogether. On my Linux and Windows machines I can run as many servers and clients as I need (I actually don't know what is the limit, I have run up to 5 servers and 3 clients without any problems).
Concerning the port bind error, you may have to configure your firewall because:
BACnet/IP is using UDP
the default port number is 47808 (0xBAC0)
Your issue might be the use of a (BACnet port #) socket that is already in-use; you have to ensure that it's not in exclusive-use - before binding to the socket, but also (slightly more) important, also ensure it's marked for reuse.
But unless you're listening for Who-Is broadcasts, I'd recommend listening for the (unicast) responses upon a different port #, e.g. 0xBAC1/47809, but still send upon the standard port # 0xBAC0/47808.
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.
I have written a TCP IP socket program which works fine.
But my socket program did not work if my server or client is behind proxy.
So how to overcome from this type of issue.
Thanks
Bapi
Well there's two issues to consider:
Behind a proxy; and
Behind a firewall.
Firewall tends to be easier: you simply use port 80 (HTTP) or 443 (HTTPS). Proxy is harder because direct network communication tends to be disabled from normal PCs.
This is why you often find people using HTTP and/or SSL as their transport mediums because they bypass these kinds of security issues. You can do push content (with long-lived connections aka Comet techniques) so there's typically no real technical reason not to.
But it's hard to say one way or the other if that's a good idea or not without knowing more about your application and any pertinent requirements.
Proxies usually work at the application level, not at the transport level.
Here is some information about Java and proxies.
Depending on the proxy, there may be little that you can do. If the Proxy is designed to block all traffic that it does not directly handle, then you have to either go through the proxy, somehow working with it, or you have to find a way to sneak through the proxy.
For example, many applications are built on top of HTTP precisely because it is commonly allowed through firewalls and is commonly proxy-friendly. Thus, it's a pretty safe way of communicating when you know that you'll be installing the application in environments where proxies may exist.
In your case, it depends on what port(s) your application uses, on whether these ports are commonly handled by a proxy for any existing protocol, on whether or not you're using a standard (commonly known) protocol or have invented your own, and so on.
Is this proxy a transparent proxy? (That is, do web browsers have to be configured to see it, or not?) The kind of proxy it is determines part of how your application needs to work with it. Is the proxy controlled by your organization?
You say you are using port 5018. Just as an experiment, can you try using port 80? Just because you're using port 80 doesn't mean you have to use HTTP. This is worth a try to see if it helps.