The future of PolyORB and the DSA

Yes this is exactly what I meant.

As I said I implemented the annex for processes running on the same box. The communication is done by streams sitting on top of shared memory regions and system wide events (Windows, Linux). But I could not make GNAT to accept it.

The next step would be using TCP sockets with No_Delay options as the transport. No ZeroMQ, of course. You could add symmetric encryption with periodic key changes for paranoid people on top. Symmetric encryption guaranties zero payload overhead. I did all that for out commercial middleware.

1 Like

Just for fun I read a bit of the exp_dist package and the first thing it says is:

package Exp_Dist is

   PCS_Version_Number : constant array (PCS_Names) of Int :=
                          (Name_No_DSA      => 1,
                           Name_GARLIC_DSA  => 1,
                           Name_PolyORB_DSA => 6);
   --  PCS interface version. This is used to check for consistency between the
   --  compiler used to generate distribution stubs and the PCS implementation.
   --  It must be incremented whenever a change is made to the generated code
   --  for distribution stubs that would result in the compiler being
   --  incompatible with an older version of the PCS, or vice versa.

So it seems that GNAT needs to be made aware of the PCS system and then the PCS system should populate the Stubs from the compiler. So technically quite portable, but it will likely require some hacking around the compiler. So not super portable.

Best regards,
Fer

I’ll try to look at the polyorb generated gpr’s to hopefully glean some clues for this in the next day or so.

I did notice some parts of the gpr’s which might relate to the process, in passing, when debugging some other PO issues. Still, I’m only big toe deep in the PO/DSA code :slight_smile:, so far.

Hi @darek,

Have you made any progress with the suggestions I made earlier ?

Honestly, I rather dislike the “generate a file that generates a build” (eg [autotools →] ./configuremake ); it may be worth it to disentangle (and remove dependencies)… but that can be a lot of work.

Hi,

Thank you very much for your message. I was dragged to another project therefore I could not immediately test your solution.

Finally, I did the following:

  • modify the code according to your suggestions.
  • build the binaries with all partitions running on a single machine.

The single machine configuration works OK.

Then, I tried to run in on separate machines. I have generated and installed the ssh-key on the all required computers.

The compiler builds the code correctly.

I did tests with:

< pragma Name_Server(Standalone)> and <pragma Name_Server(Embedded)>.

I have started the name server by executing:

              po_cos_naming &

this produced a very log sequence staring with POLYORB_CORBA_NAME_SERVICE=IOR: ….LOTS OF DIGITS (and some letters) HERE …POLYORB_CORBA_NAME_SERVICE=corbaloc:iiop:1.2@192.168.100.15:46867/NameService/000000024fF0000000080000000

I did the following (copy only up to POLYORB_CORBA_NAME_SERVICE string):

export POLYORB_DSA_NAME_SERVICE=IOR:……

./run_dsa

At the terminal where po_cos_naming run, I got (please note the node_01 is not mentioned below) :

cosnaming.namingcontext: look for "AAAA	polyorb.dsa_p.partitions	RCI;"
cosnaming.namingcontext: look for "AAAA	polyorb.dsa_p.partitions	RCI;"
cosnaming.namingcontext: register "AAAA	polyorb.dsa_p.partitions	RCI;" in naming context
cosnaming.namingcontext: append "AAAA	polyorb.dsa_p.partitions	RCI;" to naming context
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT
cosnaming.namingcontext: look for "AAAA	calc_node_02	RCI;"
cosnaming.namingcontext: AAAA ... polyorb.dsa_p.partitions	RCI	NOBJECT

At the execution terminal I got:

./run_dsa 
bash: line 1: /dev/shm/node_01: No such file or directory
bash: line 1: /dev/shm/node_02: No such file or directory

raised SYSTEM.RPC.COMMUNICATION_ERROR : lookup of RCI calc_node_02 failed

For the build with pragma Name_Server(Embedded), I got

./run_dsa 
bash: line 1: /dev/shm/node_01: No such file or directory
bash: line 1: /dev/shm/node_02: No such file or directory


raised SYSTEM.RPC.COMMUNICATION_ERROR : lookup of RCI calc_node_02 failed

When I activated options:

for node_01’self_location use (“tcp”,“192.168.100.11”);

for node_02’self_location use (“tcp”,“192.168.100.11”);

in the .cfg file, and build application with the embedded name server I got:

./run_dsa 
bash: line 1: /dev/shm/node_01: No such file or directory
bash: line 1: /dev/shm/node_02: No such file or directory

raised CONSTRAINT_ERROR : polyorb-references.adb:443 explicit raise

With the pragma standalone name server the error is similar.

I guess, there is something missing from my side.

Regards,

Darek

P.S. The code on the gitlab has been updated.

Hi @charlie5 ,

I got the DSA up and running on 3 machines. This evening (the CET time zone) I will try to update the gitlab repository with the working example.

Thanks again for your help.

Darek

P.S. The Darek Maksimiuk / dsa_dev · GitLab has been updates with (I hope working for others as well) solution.

4 Likes

Hi @darek,

Well done getting DSA running on the different machines. You use different Polyorb/DSA config options than I, so I will be interested in looking at your solution.

As a final minor note, you should be able to use the shorter

corbaloc:iiop:1.2@192.168.100.15:46867/NameService/000000024fF0000000080000000

when you export POLYORB_DSA_NAME_SERVICE.