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.
Related
I'm looking for a secure way to tunnel RMI traffic.
In My application(java Webstart) i must assume that the only port that is open is port 80.
I have the looked att socketfactories for rmi but do i really need a proxy then.
I need to do all my tunneling on the client side.
The only firewall i am trying to get past is on the client side.
I'm not able to open 1099 with port ranges above.
Would be nice to see some implementations.
Thanks!
Port 1099 was reserved for RMI at IANA in about 1995. There is no reason for it not to be open for outbound access in the client-side firewall.
RMI can be made to use fixed port numbers by supplying a port number when constructing (super(port)) or exporting (exportObject(object, port)). Better still, if you create the Registry within the server JVM via LocateRegistry.createRegistry(), all subequently exported remote objects will use that port unless they specify a different port or they use a server socket factory.
BUT ... RMI already includes HTTP tunneling 'out of the box'. No external solution required. You have to deploy the RMI-Servlet provided with the JDK, at the server end.
(a)
although not the newest fashion, exposing remote services with Hessian and Burlap seems to be a simple solution to avoid problem working across firewalls: http://hessian.caucho.com/doc/
see sample code for the server and client side:
http://www.javatpoint.com/spring-remoting-by-hessian-example
(b) or consider using Spring HttpInvokder (see some sample code here: http://www.javatpoint.com/spring-remoting-by-http-invoker-example)
HttpInvokder provides more customization options through the RemoteInvocationFactory, RemoteInvocationExecutor and HttpInvokerRequestExecutor strategies (for example, to add custom context information (such as user credentials) to the remote invocation, or using java’s built-in object serialization etc.), see:
http://docs.spring.io/spring-framework/docs/2.0.x/api/org/springframework/remoting/support/RemoteInvocationFactory.html
I need to test a functionality internal to my company's server whose benefit is evident only when clients run slow (as of latency and packet loss). To that extent, I need to simulate clients on a slow and/or lossy connection (TCP/HTTP). I'm using a Mac, Mountain Lion, and ideally I'd need to run both server and client locally.
One approach I tried to pursue -- unsuccessfully -- was to get hold of some java APIs that allow me to build clients with slow connections. I know JMeter has got something called SlowSockets (or something similar), but I was looking for APIs more focused on slow-performing clients. Any ideas of useful APIs?
Another approach I tried consisted in using a proxy to act as a middleman between client and server. In that case, the proxy should provide functionalities for simulating slow links. I've tried Charles proxy (Mac) and Apache TCPMon, however I seem to miss something when I try to get them at work. With TCPMon, for instance, when I start it in 'Proxy' mode (which is the mode that offers the 'simulate slow link' functionality) I define port for the local proxy, but I can't see how to define the remote host and port. Something similar happens with Charles Proxy; I can set the local port in the Proxy settings, but I can't understand how to define the remote end of the proxy (in fact connections fail saying the remote server is not responding). Anyone having ideas what I'm doing wrong?
One further approach I have tried to pursue is by using lower-level (e.g. OS-based) means; in this case, I tried Apple's Network Link Conditioner. I switched it on and defined my slowness parameters, but when I ping I don't seem to see the expected RTT etc. I've got a feeling NLC has a tight relationship with XCode and iOS testing, anyone capable of putting it at work for testing other (e.g. Java) applications? I've also tried ipfw on Mac, however the manual says ipfw is now deprecated and I don't want to dedicate time to get to know a tool that won't be available soon.
Any idea/help will be highly appreciated.
Thanks in advance.
I've got a web service which may be bound either to ssl or plain http. The java clients configured to know the server host and port. When client connects, I construct the server end point like http://host:port/service. Clients don't have a knowledge whether the server is using ssl - server always binds to a single port so that it's either secure or not. Now, the question is how to make a client to discover this without introducing another parameter? Can I challenge plain http request and then fall back to ssl (or vice verse) on a certain exception? Or I must explicitly introduce new connection parameter for the clients?
On the server side, you could use a mechanism like Grizzly's port unification implementation. This can be used to serve HTTP and HTTPS on the same port. This relies on the fact that in both cases, the client talks first and either sends an HTTP request or an SSL/TLS Client Hello message. It's quite handy for this on the server side (although I'm not sure I'd recommend running two protocols on the same port in general).
From the client's point of view (which is what you're asking about), the consequences of that are:
The fact that the client talks first means that it will always have to try first. Expect an exception of some sort if you try to talk SSL/TLS to a plain HTTP service and vice versa.
If the server uses port unification, there is no way you're going to be able to find out reliably.
Port unification aside (this is a rare case after all), you could try to cache results of past attempts.
More fundamentally, from a security point of view, not knowing which protocol should be used introduces a vulnerability: your system will be open to downgrade attacks (in a similar way as blindly relying on automatic redirects would). If your user-agent supports HSTS, it would be worth looking into that (although it would require the user-agent to remember which sites are to be used with HTTPS).
Either way, if you're concerned about security, you must configure the client to know when to use https://.
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.
How can I use RMI with a applet client behind a firewall?
How can I use RMI with a firewalled server and firewalled applet client? (If possible)
I know that the RMI server uses port 1099 (by default, but this is configurable); however after this the communication requires a new socket on a different random port. I also know that you can set the proxy on the client for RMI over HTTP tunneling which in theory should solve my issue. But I can't make it work (I tried setting the environmental properties on my XP client, but Internet Explorer keeps ignoring them).
See http://java.sun.com/javase/6/docs/technotes/guides/rmi/faq.html#firewall
If the servers code is in your hand you could also restrict RMI to use a predifined port by providing a custom RMISocketFactory as described here: http://insidecoffe.blogspot.com/2012/02/firewall-friently-rmi-port-fixing.html
(Note specially the hint that it may cause problems if you use JMX in parallel)
Have not looked into it to deeply my self yet, but while looking around for a project I am currently doing I came accross LipeRMI.
You might want to have a look at it as it geared towards internet usage and mentions "shadow the clients in such way they can be behind a local network, router or firewall;"
Edit:
Remembered another implementation I came across a while back called RMI Doves 1.0: Solution for Java RMI firewall problem you might want to have a look at that one as well.
in your Server put the code like this:
RmiInterface stub = (RmiInterface) UnicastRemoteObject.exportObject(rmi, 35400);
LocateRegistry.createRegistry(1099);
Naming.rebind("//192.168.102.128:1099/rmi", stub);