Archived
This forum has been archived. Please start a new discussion on GitHub.
Virtual Machine Port Renaming Stalls
If you set up a virtual machine on your current computer (I used VirtualBox) and setup port forwarding so the host os's port doesn't match the guest os's port, Ice will hang if you try to use an object that was created server side and returned through an interface.
Currently my application can configure the port on one side, but not the other (I haven't added the feature to configure it on the other side yet). I'm using port 10000 for all communication. I assigned the host os to port 12000 and had it forward to the guest OS's port 10000. Here's the log output with Ice.Trace.Network set to 3.
For the host os (this is the client).
For the guest os (this is the server).
Included are my own logging messages (as they may be helpful to explain what I think is happening).
In my own output, I see that one of the calls succeeds. I believe it starts failing after I use a factory function to create a new Ice object and return that object. Then it tries to call a function on that proxy and it hangs (no idea why it doesn't just refuse the connection).
It seems to try communicating with port 10000 on the client side when it should always try to communicate with 12000.
Not sure how you would fix this (or if it's even possible) as the server doesn't have any knowledge that it should use port 12000 instead, and the client has no knowledge it's being forwarded to 10000. All connections are on localhost and port 10000 isn't open on that machine, so I don't know why it isn't failing (the call that it's using is idempotent, so maybe it would eventually fail after a timeout?).
Server is on Ubuntu 10.10 using Ice 3.3.1 and Python 2.6.
Client is on Fedora using Ice 3.4.0 and Python 2.7.
Not sure if this is a bug or a big "warning" label for others trying to debug the same thing.
Currently my application can configure the port on one side, but not the other (I haven't added the feature to configure it on the other side yet). I'm using port 10000 for all communication. I assigned the host os to port 12000 and had it forward to the guest OS's port 10000. Here's the log output with Ice.Trace.Network set to 3.
For the host os (this is the client).
[ 2011-03-29 00:18:27.783615 ./guitar: Network: trying to establish tcp connection to 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.783953 ./guitar: Network: tcp connection established local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.786912 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.787187 ./guitar: Network: sent 73 of 73 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.791870 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.791973 ./guitar: Network: received 12 of 12 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] INFO: 2011-03-29 00:18:27,792 1 machine(s) available [ 2011-03-29 00:18:27.792584 ./guitar: Network: sent 50 of 50 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.105596 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.105699 ./guitar: Network: received 156 of 156 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] INFO: 2011-03-29 00:18:28,105 fedora: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (fedora-52.1.9.7.fc14-i386) OpenJDK Client VM (build 19.0-b09, mixed mode) [ 2011-03-29 00:18:28.106195 ./guitar: Network: sent 143 of 143 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.176206 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.176306 ./guitar: Network: received 80 of 80 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:33.180450 ./guitar: Network: trying to establish tcp connection to 10.0.2.15:10000 ] [ 2011-03-29 00:19:33.778269 ./guitar: Network: sent 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:19:38.323214 ./guitar: Network: closing tcp connection local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ]
For the guest os (this is the server).
[ 2011-03-29 00:18:27.783615 ./guitar: Network: trying to establish tcp connection to 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.783953 ./guitar: Network: tcp connection established local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.786912 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.787187 ./guitar: Network: sent 73 of 73 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.791870 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:27.791973 ./guitar: Network: received 12 of 12 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] INFO: 2011-03-29 00:18:27,792 1 machine(s) available [ 2011-03-29 00:18:27.792584 ./guitar: Network: sent 50 of 50 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.105596 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.105699 ./guitar: Network: received 156 of 156 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] INFO: 2011-03-29 00:18:28,105 fedora: java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (fedora-52.1.9.7.fc14-i386) OpenJDK Client VM (build 19.0-b09, mixed mode) [ 2011-03-29 00:18:28.106195 ./guitar: Network: sent 143 of 143 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.176206 ./guitar: Network: received 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:28.176306 ./guitar: Network: received 80 of 80 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:18:33.180450 ./guitar: Network: trying to establish tcp connection to 10.0.2.15:10000 ] [ 2011-03-29 00:19:33.778269 ./guitar: Network: sent 14 of 14 bytes via tcp local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ] [ 2011-03-29 00:19:38.323214 ./guitar: Network: closing tcp connection local address = 127.0.0.1:47053 remote address = 127.0.0.1:12000 ]
Included are my own logging messages (as they may be helpful to explain what I think is happening).
In my own output, I see that one of the calls succeeds. I believe it starts failing after I use a factory function to create a new Ice object and return that object. Then it tries to call a function on that proxy and it hangs (no idea why it doesn't just refuse the connection).
It seems to try communicating with port 10000 on the client side when it should always try to communicate with 12000.
Not sure how you would fix this (or if it's even possible) as the server doesn't have any knowledge that it should use port 12000 instead, and the client has no knowledge it's being forwarded to 10000. All connections are on localhost and port 10000 isn't open on that machine, so I don't know why it isn't failing (the call that it's using is idempotent, so maybe it would eventually fail after a timeout?).
Server is on Ubuntu 10.10 using Ice 3.3.1 and Python 2.6.
Client is on Fedora using Ice 3.4.0 and Python 2.7.
Not sure if this is a bug or a big "warning" label for others trying to debug the same thing.
0
Comments
-
Hi Jonathan,
You just need to set the PublishedEndpoints property on your object adapter to publish proxies with the desired port.
See http://www.zeroc.com/doc/Ice-3.4.1-IceTouch/manual/Adv_server.33.4.html
Cheers,
Bernard0 -
That's... perfect. Exactly what I need.
Thanks!
I guess it wasn't really a bug then.0
