Archived
This forum has been archived. Please start a new discussion on GitHub.
Callbacks in Glacier2
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.
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.
0
Comments
-
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.0
-
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.0 -
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.0 -
Your suspicions are well-founded.
Thank you,
David.0