[PolyORB-users] 2 client/server communication with DIOP

Jerome Hugues hugues at infres.enst.fr
Fri Mar 18 14:40:31 CET 2005


Hi Selim

Selim Belbachir (selim.belbachir at fr.thalesgroup.com):

> I managed to make work the 'echo' example with DIOP by replacing the IDL
> "string echoString (in string Mesg);" method by "oneway void echoString
> (in string Mesg);".
> So I obtained a client <-> server communication.

You mean client -> server, don't you ?

There should not be any server -> client communication with DIOP.

> Now I would like to build a client/server <-> client/server
> communication so I wrote this IDL :
> 
> interface Avatar {
>     oneway void Move();
> }
> 
> interface World {
>     oneway void GiveAvatar(in Avatar A);
> }
> 
> Avatar is implemented in exeA and World in exeW.
> 
> I first launch exeW which prints the World IOR. Then I launch exeA with
> World IOR as first parameter and call the 'GiveAvatar' method with the
> object reference I obtained from the World IOR.
> 
> My exeA is blocked during the 'GiveAvatar' request. I cannot figure out
> why...

What is the configuration of each node ? You mention you use the
No_Tasking profile. Can you detail the setup file you use. What is the
content of your polyorb.conf file (only the uncommented please) ?

For that kind of exploratory work, I suggest you compile with debug
activated. If this is done, please display debug for polyorb.orb, this
would provide some information on what the ORB is doing.

Besides, I do not understand how a No_Tasking server could make sense.
You need at least two tasks: one for the server role, one for the
client role, or do you use one thread that alternates both role ?
 
> I tried my executables with IIOP instead of DIOP and it worked ! I even
> was able to call Avatar back with the 'Move' method from exeW ! Am I
> missing something about DIOP?

I don't think so. 

Did you just change the polyorb.conf file, or did you also modified
the executables ?

> (I also noticed that the World corbaloc printed out by exeW refered to
> diop1.0 and not 1.2. Is is normal?)

Humm, DIOP uses GIOP 1.2, so I think we should bump it to version 1.2

Thanks for reporting this issue.

-- 
Jerome


More information about the PolyORB-users mailing list