Callbacks in Glacier2

[davidcr1983]

Hello!

I am developing a render grid under the architecture of a multi-agent system, in which main services are located through IceGrid and agents are in Internet. I use Glacier2 to allow agents to contact with the main services, and I use callbacks to permite main services to notify new works to agents.

When a service (Service A) notifies a new work to an agent, this agent gets the notification correctly, but it locks itself when it tries to get data from another service (Service B: different to the Service A, which notifies the work). This last action is performed when the callback is done by the ServiceA.

I enable the log, but it doesn't appear any conflict.

An important question is that agents are subscribed to the Service A previously, and this subscription consists in that an agent supplies a proxy to the callback object. This way, Service A can iterate through its list of agents and it can notify the new work. I am confused with this approach, and I don't know if it is a correct form of operate in such context.

I would like to use callbacks because agents will be behind a firewall and callbacks allow me to solve the problem which represents an hostile network environment.

Thank you very much,
David.

[matthew]

What version of Ice are you using? What operating system? A diagram of the calling sequence and where the various services are located in the network particularly in respect to inside/outside of the firewall would be helpful.

[davidcr1983]

I use Debian Sid, Ice 3.1.0, and Python.

Currently, I am developing the system in my notebook, which is in a local area composed of three computers behind a firewall. Therefore, all the services and the agents are being executed in my notebook. I have forwarded the port 8000 to Glacier2, which is executed in my notebook (192.168.1.4).

This is the calling sequence:

1.- An agent starts up and execute the operation 'subscribe' of the service A:

interface Master {
....
void subscribe(string agentName, RenderAgent* agent);
....
};

2.- The service A has a dictionary <agentName, prxAgent> and add the new entry.

3.- A new work is notified to the service A. Then, the service A notifies the new work to its subscribed agents:

interface RenderAgent {
....
void notifyNewWork(TZones zones, int idWork, int benchmarkValue);
....
};

4.- An agent tries to get data from the service B. It uses the registry of the IceGrid service to resolve indirect proxies. This is the interface of the service B:

interface ModelRepository {
....
nonmutating string get(int idModel, out ByteSeq model);
....
};

5.- The agent locks in this step.

This is the glacier2router config file:

Glacier2.Client.Endpoints=tcp -h 192.168.1.4 -p 8000
Glacier2.Client.PublishedEndpoints=tcp -h ladorada.dyndns.org -p 8000
Glacier2.Server.Endpoints=tcp -h 192.168.1.4
Glacier2.CryptPasswords=config/passwords.cfg
Ice.Default.Locator=IceGrid/Locator:tcp -h 127.0.0.1 -p 10000

#Other properties
Ice.Trace.Network=2
Ice.MessageSizeMax=20480

And this is the agent config file:

Ice.Default.Router=Glacier2/router:tcp -h ladorada.dyndns.org -p 8000
MyAdapter.Router=Glacier2/router:tcp -h ladorada.dyndns.org -p 8000

Ice.ACM.Client=0
Ice.MonitorConnections=60
Ice.RetryIntervals=-1
Ice.Trace.Network=2
Ice.MessageSizeMax = 20480
Ice.Warn.Connections=1

Thank you,
David.

[matthew]

I suspect you need to increase the size of the client side thread pool in the agent. Try setting:

Ice.ThreadPool.Client.Size=<some value more than 1>

You can read more about this in the Ice manual in section 34.7.

[davidcr1983]

Your suspicions are well-founded.

Thank you,
David.