connection reset by peer when I specify port for Callback
I have a successful rmi callback when it uses annoymous port by using UnicastRemoteObject.exportObject(this) from client. But I get the following messages when I tried to specify port by using UnicastRemoteObject.exportObject(this, port) by client. My understanding is this tells the server to callback using the port specify and the connection should be made. Where it fails is when the server tries to call client.notify() where the callback is taking place I get the errors.
Am I missing something? I thought that was all I needed to do to specify a port.
Remote Exception:java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.MarshalException: Error marshaling transport header; nested exception is:
java.net.SocketException: Connection reset by peer: Connection reset by peer
java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.MarshalException: Error marshaling transport header; nested exception is:
java.net.SocketException: Connection reset by peer: Connection reset by peer
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
Thanks for the help.
# 1
What port did you use?See here: http://www.iana.org/assignments/port-numbers
# 2
I tried out using different port numbers. I even tried using the one that worked in annoymous by printing them out then recompile/run using that port but I get the same thing.
# 3
Let's try it again. What port did you use? Is it from 49152 through 65535? What is client.notify()? is this an override for Object.notify()?
# 4
I used port 4111 and tried many from 2000-5000. Client.notify() was just an example of function that calls method in client from server. Sorry for confusion. I'll give better name say letsCallBack.
Client.letsCallBack() is the call from the server to client. This is the callback. It crashes on this and doesn't get to the letsCallBack method in client printing out the exceptions you saw above.
Thanks for help.
# 5
That exception is happening in the callback.. What is it trying to do to the network? another RMI call? create a Socket?
ejpa at 2007-7-12 20:45:54 >
# 6
Yes, exception is happening in the callback but I don't understand why. Callback works fine when I don't specify port by using UnicastRemoteObject.exportObject(this). But when I specify port by UnicastRemoteObject.exportObject(this, 4111) it won't callback...
On client's side, I printed out the port and netstat and it is listening on 4111. So..could this be somehow why server is using different port to callback on client?
any suggestions on what causes these exceptions will be apprciated.
Thanks.
# 7
No. The exception is happening inside the callback method while it is running. So the callback mechanism is working. It's working really well, it's even throwing an exception back to the caller.The question here is what is the callback method doing at that line of code?
ejpa at 2007-7-12 20:45:54 >
# 8
Here is simplified version of the code.
//make client
//make server
//register server with client
//register client with server
server.execute();
In server code there is execute method which does following:
public void execute( ) throws java.rmi.RemoteException {
String msg = "Executing";
client.callback(msg);//fails here
..
..
..
}
And in client code there is callback method which does following:
public void callback(String msg) throws RemoteException {
System.out.println("message from Server " + msg); //never gets printed out
..
..
..
}
Seems pretty straight forward...any suggestions?
Thanks.
# 9
Can you show the complete stack trace, and specify whether it is the client or the server that prints it.
ejpa at 2007-7-12 20:45:54 >
# 10
I was using UnicastRemoteObject the wrong way.
When I specify the port number on the client it was listening on that port for callback which wasn't necessary. I just wanted the server to use a specific port to talk to client. I changed the server to use UnicastRemoteObject(this, 4111) which caused it to callback on 4111 which is just the behavior I wanted to achieve.
Thanks.
# 11
Im not so sure if what I said above is actually true......
Back to the original problem.
Basically my Java GUI application does not work over the VPN because of firewall. I don't have any firewall on the client side so from what I read, I can make this work by requesting a specific port to firewall admin to be opened up.
Even before the VPN issue Im just trying to have server to callback on a specific destination port on LAN where there is no firewall on either side. So how do I tell the server to know that the destination port will be 4111? I tried doing
super(4111) on the client class which extends UnicastRemoteObject and when I netstat it shows its listening on 4111.
But I get those errors you see above thrown from server side.
# 12
Hi Esmond, My name is Lee and I work with Joon (hellscream) and this RMI callback problem still persists. We appreciate your help and we know about your expertise in this area. (Great products on your web site by the way).
The problem environment currently consists of a Unix Solaris server on the backend and windows XP laptops acting as clients. The callback is from the unix server back to the client.
By looking at the output of netstat -na on the unix server during a normal anonymous port run, we can clearly see that there seem to be 3 sequentially numbered ports involved whenever the anonymous port construct of UnicastRemoteObject is used. This happens with super() or super(0); in our client code. All works very well that way.
The problem arises when we make changes to the client impl file and specify a port with super(65000) for example.
There is no firwall involved right now and UnicastRemoteObject doesn't seem to behave as advertised in the sense that
We can clearly see what's going on with the network using Thread.sleep(10000) within the client app meanwhile executing netstat -na on the unix server and grepping for the client IP address
We can see that the unix server STILL wants to talk to the client on an arbitrary port while the laptop client is listening on the desired port that we chose (65000) in this case.
If we attempt to instantiate a port in the server Impl java file, the results are the same with the exception of the choice of the source port on the unix server. We seem to be able to choose and set that at will. Unfortunately, and from the perspective of a future firewall, the source port is irrelevant and the rules normally apply to destination ports in an outgoing connection.
Anyway, with ports instantiated and everything compiling, the client prints the following stacktrace
Thanks very much in advance for your help
Remote Exception:java.rmi.ServerException: RemoteException occurred in server th
read; nested exception is:
java.rmi.ConnectIOException: error during JRMP connection establishment;
nested exception is:
java.net.SocketException: Connection reset
java.rmi.ServerException: RemoteException occurred in server thread; nested exce
ption is:
java.rmi.ConnectIOException: error during JRMP connection establishment;
nested exception is:
java.net.SocketException: Connection reset
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:292)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4
60)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:701)
at java.lang.Thread.run(Thread.java:534)
at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(Stream
RemoteCall.java:247)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:
223)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:133)
at ids.rmi.ServerJobImpl_Stub.execute(Unknown Source)
at ids.jobExec.JobThread.run(JobRunner.java:551)
Caused by: java.rmi.ConnectIOException: error during JRMP connection establishme
nt; nested exception is:
java.net.SocketException: Connection reset
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:274
)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:171)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:101)
at ids.rmi.JobClientImpl_Stub.message(Unknown Source)
at ids.rmi.ServerJobImpl.execute(ServerJobImpl.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
at sun.rmi.transport.Transport$1.run(Transport.java:148)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:4
60)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport
.java:701)
at java.lang.Thread.run(Thread.java:534)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:183)
at java.io.BufferedInputStream.read(BufferedInputStream.java:201)
at java.io.DataInputStream.readByte(DataInputStream.java:331)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:215
)
... 15 more
Job finished. Exit status: -1
# 13
OK so this exception is happening in the server while it is trying to execute the callback. It is looking like a firewall issue now.
BTW the host executing the remote call will always use a random outbound local port when connecting to the remote object, but it will use as the remote target port the port number on which the remote object was exported. Is that what netstat is showing?
ejpa at 2007-7-12 20:45:54 >
# 14
Hi Esmond, thanks for looking at our problem. Yes, netstat shows 3 randomly chosen ports at the very beginning and later and during the callback also shows three ports (sequentially numbered) . The lowest port is what the client listens in on.
Initial netstat output at start of program
172.26.74.170.22172.24.85.72.12816543947 248200 ESTABLISHED
172.26.74.170.1251172.24.85.72.1867650980 248200 ESTABLISHED
172.26.74.170.44655 172.24.85.72.1869652290 248200 ESTABLISHED
172.26.74.170.44614 172.24.85.72.1870651620 248200 ESTABLISHED
the .170 address is the unix box and the .72 address is my laptop client. Port 22 is my ssh session into the box. The rmi server port is 1251. Everything is set to anonymous port usage with UnicastRemoteobject and the program works. There is no firewall and no VPN between the unix box and the client.
2 minutes after starting the program on the client, and without clicking on anything at all, the three connections above die out and only my ssh connection remains
172.26.74.170.22172.24.85.72.12816531147 248200 ESTABLISHED
During the callback, and when I actually hit the part of the code that executes the callback, we see the following:
172.26.74.170.22172.24.85.72.12816526347 248200 ESTABLISHED
172.26.74.170.44655 172.24.85.72.1915653580 248200 ESTABLISHED
172.26.74.170.45829 172.24.85.72.1914655350 248200 ESTABLISHED
172.26.74.170.44655 172.24.85.72.1917653320 248200 ESTABLISHED
Our assumption is that we should be able to instantiate whatever ports are used on the client for these connections then simply open up the three ports on the firewall which we will have to face when moving all of this to VPN. Seems like a reasonable assumtion no?
Again, by manipulating unicastremote object, we were able to make the client listen on the desitred port and were able to make the unix box use a specific source port but the target ports on the remote laptop are still chosen randomly hence the marshalling transport header error. I guess the Unix box is calling the laptop on a port that the laptop is NOT listening on. Please remember that there is no firewall currently. According to EVERYTHING I've read so far, this should work but it doesn't.
Needless to say I'm a little disheartened with Java's network programming model and much prefer the old stuff using C and sockets. It seems that a lot is hidden from you only to have those sections behave erratically and not according to spec. Wow!!!
Anyway, thanks again for your help. I hope you see something that might help us.
Lee Farah
# 15
The fact that you got a 'connection reset' also shows that you got a connection, so the ports are working. I'm confused by your description but you need to understand that the outbound port from a client connect is always random and the target port will be whatever the UnicastRemoteObject is exported on.
Can you show the *complete* stack trace of the MarshalException?
Re Java network models, RMI is only one of them. If you want plain sockets they are there too, much nicer than C believe me, and there are several more models. I would agree that RMI makes too much of an effort to conceal TCP, as though there was ever going to be any other transport. It hasn't happened yet in ten years.
ejpa at 2007-7-21 22:46:50 >
