Troubles with the Glacier2 Demo

AlexBell

Context: Ice 3.3.1, JDK 1.6. Windows XP

I have followed the directions in the README file contained at:
C:\Ice-3.3.1-VC90\demoj\Glacier2\callback

All four of the executables are being launched on the same box. The Server starts up fine, the SessionServer starts up fine. However, when it comes time to fire up glacier2 a la "glacier2router --Ice.Config=config.glacier2", I get a socket exception (WSAEADDRNOTAVAIL) network.cpp:1083....and the party quickly ends.

However, if I change this:

Glacier2.Client.Endpoints=ssl -p 4064 -h 24.16.105.214

to this:

Glacier2.Client.Endpoints=ssl -p 4064 -h 127.0.0.1

The glacier2router comes up fine....as does the subsequent launching of the client....all works fine.

I enabled port forwarding for ports 4060-4065 to the internal IP where the test is running in my linksys router configuration....but no luck. Windows firewall is off...and I have no other software firewall. I have also enabled "anonymous requests from the Internet" as being ok. I have temporarily opened up all ports via DMZ....and still no luck.

I telnet to my machine from on the internet at port 4064...connection refused...maybe that is expected. netstat -a shows 4064 established.

What boneheaded thing could I be doing wrong? I am using config files as is in the directory above except for swapping out internal/external IPs.

Thanks....

ALex

benoit

Hi Alex,

Is the 24.16.105.214 IP address the address of your Windows XP machine or is it the public IP address of your Linksys router? If it's the address of your router, you should setup the Glacier2 endpoints with the internal IP address of your machine instead of the Linksys router IP address. So for example if the internal IP address is 192.168.1.100:

Glacier2.Client.Endpoints=ssl -p 4064 -h 192.168.1.100

And then forward traffic on the port 4064 of your Linksys router to this IP address and port.

The address specified with the Endpoints property specifies the network interfaces the server will listen on so it's important to only list IP addresses that are linked to a network interface of the machine. To ensure proxies created by an object adapter include the "public" address, you can use the PublishedEndpoints property. Note however that this isn't necessary for Glacier2 since it doesn't "export" proxies. For more information on Ice object adapter endpoints see this section in the Ice manual.

Cheers,
Benoit.

AlexBell

Thanks Benoit.....I will try this tonight. I suppose I was misled by the following fragment in the config.glacier2 file:

#
# The client-visible endpoint of Glacier2. This should be an endpoint
# visible from the public Internet, and it should be secure.
#
Glacier2.Client.Endpoints=ssl -p 4064 -h 24.16.105.214

I was seemingly following the recipe....??? This is what led me to do as I did....

Thanks again...

ALex

AlexBell

Benoit...

If I am being a fool....I apologize for wasting your time. But, everything I have read in the Ice documentation, as well as the commentary in the config.glacier2 file calls for the following property to be an address that is visible on the public internet as opposed to the internal 192.x.x.x address you suggested that I change this to in an earlier post:

Glacier2.Client.Endpoints=ssl -p 4064 -h 24.16.105.214

For example, section 42.4.3 in the 3.4.1 version of the Ice documentation contains the following fragment defining the client endpoint for a non-SSL connection and uses a *public* address (5.6.7.8):

Glacier2.Client.Endpoints=tcp ‑h 5.6.7.8 ‑p 4063
Glacier2.Server.Endpoints=tcp ‑h 10.0.0.1

Anyway....glacier2 does crash when I set the property as follows:

Glacier2.Client.Endpoints=ssl -p 4064 -h 24.16.105.214

but this appears to me to be the correct setting as it is the address of my router which is the only public IP I have.

Clearly....I am missing something here....and appreciate your patience....thanks.

ALex

benoit

Hi Alex,

The client endpoint is the one receiving client connections and the one which must be accessible to clients. It can be visible from the public Internet either because it contains an Internet IP address or because a firewall device redirects traffic to it. There are indeed two main scenarios possible for the machine hosting Glacier2:

• It's connected to the internet and it has a public IP address accessible from the Internet.
• It's behind a firewall/NAT device and it doesn't have a public IP address accessible from the Internet.

In the first scenario, it's simple you just have to set the internet IP address in the Glacier2 client endpoints. In the second scenario, you have to set the machine's internal IP address in the Glacier2 client endpoint and you have to setup your firewall to re-direct traffic from a given port to the Glacier2 client endpoint. This scenario is described in more details in the manual: see 42.11 Firewalls.

By Glacier2 crashes, do you mean that it terminates abnormally or that you're getting an exception on startup? It should not crash even with some invalid configuration.

So since your machine hosting Glacier2 is behind a NAT/firewall device, you should use that machine internal IP address in the client endpoint (one of the IP addresses returned by "ipconfig /all" and the one that the NAT/firewall device can talk to). You should also setup your NAT/firewall device to redirect traffic to this address (either by setting a DMZ or by re-directing the traffic of a given port).

Let us know if this still doesn't work!

Cheers,
Benoit.

PS: You should consider upgrading to the latest Ice version.

AlexBell

Ok thanks....I will try this tonight. In regard to upgrading, I originally attempted my experimentation with the latest and greatest but my end goal here is an Android app and I was not able to get the "weather publisher" example working on the latest and greatest (I think I had read that the Android Ice impementation had not yet been updated?).

Anyway....the weather example works fine on 3.3.1. I used all internal IPs for that example and now I am trying to get the same example working with port forwarding through a firewall using Glacier2.

When I mentioned that Glacier2 crashed, I was referring to this:

I get a socket exception (WSAEADDRNOTAVAIL) network.cpp:1083....and the party quickly ends. from my original post.

Anyway, I look forward to getting back to this tonight....and appreciate your patient guidance.

ALex

Minthos

from Appendix C: WinSock Error Reference (continued):

WSAEADDRNOTAVAIL (10049) Cannot assign requested address.

Berkeley description: Normally results from an attempt to create a socket with an address not on this machine.

WinSock description: Partly the same as Berkeley. The "address" it refers to is the remote socket name (protocol, port and address). This error occurs when the sin_port value is zero in a sockaddr_in structure for connect() or sendto().

In Berkeley, this error also occurs when you are trying to name the local socket (assign local address and port number) with bind(), but Windows Sockets doesn't ascribe this error to bind(), for some unknown reason.

Developer suggestions: Assume bind() will fail with this error. Let the network system assign the default local IP address by referencing INADDR_ANY in the sin_addr field of a sockaddr_in structure input to bind(). Alternately, you can get the local IP address by calling gethostname() followed by gethostbyname().

WinSock functions: connect(), sendto(), FD_CONNECT

Additional functions: It seems odd that the v1.1 specification doesn't ascribe this error to the function bind().

Summary: Benoit is right, you can't ask the machine to use an address that doesn't belong to it, and WSAEADDRNOTAVAIL is the error you get when you try to do it.

Ice 3.4 has some extra stuff to make Glacier easier to use. You should read the patch notes and docs for that (:

AlexBell

Thanks....

I was not sure *how* Glacier2 was using the subject property....and did not know that it *required* the socket address to be physically present on the machine that was hosting Glacier2....or if this property was magically being used undereath for other reasons. None of the user guidance that I read said anything about the constraints of setting Glacier2.Client.Endpoints. Of course it is obvious now....

Is Ice 3.4 working for Android these days? As I said, I attempted to use 3.4 and I had trouble. In searching the forums, I believe that I found discussion that the Android "version" of Ice had not been updated....and the guidance for the Android demo of "hello world" explicitly stated to use 3.3 (and I found that only 3.3.1 worked).

Again...sorry for the confusion...thanks for the support.

mes

Hi Alex,

AlexBell wrote: »

Is Ice 3.4 working for Android these days? As I said, I attempted to use 3.4 and I had trouble.

We've been doing some Android testing lately, and so far the results are promising. Preliminary tests show that the stock Ice.jar from Ice 3.4.1 works just fine in recent Android releases, at least with TCP and UDP. Note that for compatibility with Android 2.2 (Froyo), you'll need to use the workaround described in comment #10 in this bug report.

SSL is a different story. In the current Labs release of Ice for Android, we hacked up a version of IceSSL that is very different from the standard Ice implementation. This was necessary because the SSL APIs in Android were incomplete and quite buggy back then. This situation has improved a lot recently, such that our standard IceSSL implementation now requires just a few minor tweaks to work successfully with Android 2.2 or later.

What trouble were you having with Ice 3.4?

Regards,
Mark

AlexBell

I don't remember what my troubles were...but I did not try the "stock" Ice.jar file, but instead, IceAndroid.jar.

I will happily move to the "stock" Ice.jar associated with 3.4.1 as my testing is being done on Android 2.3 and I do not need SSL....yet.

So....this is what I will do tonight...and resume my Glacier2 experimentation in the context of 3.4.1. Thanks...

ALex

mes

Alex,

Just to follow up... We've released Ice for Android 0.2, which is basically just the sample programs along with a source code patch for Ice 3.4.1 and a patched version of Ice.jar.

Regards,
Mark