IceStorm behind a private net

in Help Center
Hi, I have been searching the forums and Glacier2, but I have not find a solution for my problem:
I run IceStorm in a pc with a main application that periodicaly publishes some information about different topics. On the other side I have a Siemens modem TC65 with a loaded application that tries to subscribe to any topic. The modem uses the private net of vodafone to connect to internet through an access point. The subscription is successful, but when IceStorm tries to send the published information to our modem, it is unreacheable.
How can I fix it?
Is Glacier2 the solution? If is it, I don't know the way of ussing it in these environment.
Thank you for your help in advance...
I run IceStorm in a pc with a main application that periodicaly publishes some information about different topics. On the other side I have a Siemens modem TC65 with a loaded application that tries to subscribe to any topic. The modem uses the private net of vodafone to connect to internet through an access point. The subscription is successful, but when IceStorm tries to send the published information to our modem, it is unreacheable.
How can I fix it?
Is Glacier2 the solution? If is it, I don't know the way of ussing it in these environment.
Thank you for your help in advance...
0
Comments
What can I do?
Could I fix it using bi-directional connections? I say this because the "demo/Ice/bidir/README" show this:
"This demo shows how to use bi-directional connections for callbacks. This is typically used if the server cannot open a connection to the client to send callbacks, for example, because firewalls block incoming connections to the client".
Thanks
If, however, your firewall allows a connection to Glacier2, then you're good. You can then run Glacier2 anywhere in your private network, and set the published endpoints to the firewall's IP address/port.
The client-side firewall doesn't matter, as long as you're allowed to make outgoing connections. Of course, if your client-side firewall doesn't allow outgoing connections either, then you're out of luck, too--regardless of whether you use Ice or some other middleware.
Attachment not found.
When the subscriber (modem) wants to subscribe to a topic at the IceStorm running in our computer, it uses the private network of vodafone with a private assigned address to connect to internet. At this moment moment, we can see that the subscription has finished successfully, but when the publisher sends new information, IceStorm is unable to find the endpoints of the subscriber because the private address assigned by Vodafone at the subscription time does not exist now because the connection is not persistent.
Is there any way to create a persistent connection or a "tunnel" in this situation?
Thanks for your time.
You can't directly use Ice bi-directional connections as shown in the demo/Ice/bidir example with IceStorm. Instead, you should use Glacier2. The Glacier2 process would sit between the Internet and the IceStorm service on your diagram. Your client would connect to Glacier2 and create a session. The connection between your client and Glacier2 would automatically be a bi-directional connection.
I would recommend to try the demo/Glacier2/callback or demo/Glacier2/chat demo. If possible, you could try to deploy this demo in the scenario you describe on your diagram.
The Issue 3 of the newsletter, "An Introduction to IceStorm", also has an example very similar to what you're trying to do with IceStorm, I recommend you to take a look at it and eventually try it.
Let us know if you need more information!
Cheers,
Benoit.
But in my situations I don't know how to do it, because the client is the publisher and the server is the subscriber, so who has to establishes the session with the router?, who has to allocate the SessionManager and the PermissionVerifier?
What should be the steps for the subscriber and the publisher to use icestorm and glacier2 in the previous diagram, supposing that Glacier2 is sat between internet and the IceStorm service?
Thanks for your help
Thanks
Don't get confused by the client/server in this case. These are only roles that an application plays at a given time. In this case your subscriber is both a client & a server.
The subscriber creates a glacier2 session. Then you can talk directly to IceStorm and register the object that you have created on the subscribers object adapter to receive callbacks from IceStorm when events arrive. You need to ensure the category is correct on these objects. Other than that, you don't have to do anything special.
[ icebox-IceStorm: Topic: Subscribe: U;O.]M\\OAU-qx&34(+^L/monitor ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
[ icebox-IceStorm: Flush: 1 object(s) ]
icebox-IceStorm: warning: connection exception:
SslTransceiver.cpp:336: Ice::ConnectionLostException:
connection lost: recv() returned zero
local address = 138.4.9.76:48743
remote address = 138.4.9.76:10000
[ icebox-IceStorm: Subscriber: U;O.]M\\OAU-qx&34(+^L/monitor: publish failed: SslTransceiver.cpp:336: Ice::ConnectionLostException:
connection lost: recv() returned zero ]
[ icebox-IceStorm: Flush: 0 object(s) ]
Also when I close the subscriber with C^c I obtain this exception in the subscriber terminal:
subscriber: ObjectAdapterI.cpp:767: IceInternal::ServantManagerPtr Ice::ObjectAdapterI::getServantManager() const: Assertion `_instance' failed.
Abortado
and this one in the glacier2router:
glacier2router: warning: connection exception:
SslTransceiver.cpp:336: Ice::ConnectionLostException:
connection lost: recv() returned zero
local address = 138.4.9.76:10000
remote address = 138.4.9.76:48736
Do you know what do they mean?
Thanks
The "Assertion `_instance' failed." error from your subscriber is an Ice bug which has been fixed for the next release.
I'm afraid I don't know why the publish of the event failed with the ConnectionLostException. It sounds like the IceStorm service is trying to connect to the wrong endpoints. The best way to figure this out would be to send us a small self contained example that demonstrates the problem. You could also send us the code of the client showing how you establish the connection with Glacier2 and how you subscribe to the IceStorm topic. Seeing the configuration files of your subscriber, publisher, IceStorm and Glacier2 would also be helpful.
Cheers,
Benoit.
* First I execute the icebox service: that launches IceStorm with the following configuration files ("config"), that is also used by the subscriber (I have omitted here some properties of tracing and similars):
* Then I execute the sessionserver and glacier2router with this configuration file ("config.glacier2"):
* The next step I do is to launch the publisher application. The code related with glacier2 in this application is the next:
The configuration file that this application use is the following ("config.core"):
* Finally I execute the subscriber, with the next important code (I only post the code different from other subscriber that does not use glacier2):
The subscriber uses the configuration file "config" that has been show before.
Thanks for all your help, and sorry for this huge post
The subscriber and the IceStorm service shouldn't share the same configuration file because right now the IceStorm service is configured to use the Glacier2 router client endpoints to route its outgoing requests (and this fails with an Ice::ConnectionLostException because IceStorm doesn't have any session established with Glacier2). IceStorm should transparently route requests through the Glacier2 server endpoints, without any extra configuration needed, if the proxy used by the client to subscribe is correctly created.
Only Glacier2 clients should have a router configured -- check out the configuration of the demo/Glacier2/callback or chat demos for example.
Let us know if this works better once you split the client and IceStorm configuration in 2 separate files!
Cheers,
Benoit.
Now I have to replace the local subscriber by a remote subscriber implemented with Ice-E, I will report you the results
Thank you another time
If I do not create the context and add the servant "monitor" with UUID, it does not give any exception, but the subscriber does not receive the information published by the publisher; but if I create the context, when I try to subscribe to serveral topics with the same subscriber I get this exception:
The "monitorIdent" is the same in a subscriber for all its ObjectPrx, so what can I do?
Thanks in advance
Cheers,
Benoit.
Now all is working, thanks; but the exception still appears although now I am ussing Ice-3.0.1. Is it a bug or is an error of my application?
Thanks for all your help
Yes, I believe this is a known Ice bug (bug #535 in our internal database). Just to make sure, could you get the stack trace of the assert with the debugger and post it here on the forums?
Cheers,
Benoit.
And the trace of the assert is:
In any case, this bug will be fixed in the next Ice release!
Cheers,
Benoit.
I don't call destroySession() on the router, but I suppose that the session is destroied when I puss C^c due to the shutdownOnInterrupt() command.
Thanks
The communicator shutdown (initiated by Ctrl-C) should only deactivate the object adapter of your client. Outgoing connections shouldn't be closed -- these are closed when the communicator is destroyed.
So in theory, the session and the connection to the router shouldn't be closed after waitForShutdown() returns and you should be able to invoke unsubscribe() on the IceStorm topics. Did you try to run your client with --Ice.Trace.Network to see when the connection to the router is closed? Are you correctly keeping alive the session with a separate thread (see the SessionPingThread class in the demo/Glacier2/chat/Client.cpp for an example on how to do this)?
In any case, cleaning up server resources (here the IceStorm subscribers) in the client isn't very reliable. The connection between the client and the router could be lost and the subscribers would never be unsubscribed from the IceStorm topic and this would eventually lead to resource leaks (see a recent discussion about this [post=9930]here[/post]). The right approach to cleanup server resources allocated by a Glacier2 client is to implement a session manager and clean up the resources allocated by the client in the session implementation. I recommend you to take a look at the Issue 2 and 3 of the Ice newsletter for more information and an example on how to do this.
Cheers,
Benoit.
These traces are related with this code of the client:
So, I think that the communicator is destroyed after I push Ctrl-C.
Also I have do the changes for keeping the session alive with a separate thread, but I suppose that firstly I have to fix the problem I just posted.
Thanks
So far we have been unable to reproduce this problem. It would help if you could send us an example (including config files) that reproduces the problem.
Regards,
Dwayne