libuniset2 is a library for creating ACS. It is better to see once ... Part 2 (Running the simulator)
In the previous article, I ended up creating and configuring a simulator. Now consider how to run it ...
With the launch on the one hand, everything is simple, but on the other hand there is some magic. She is quite understandable, if "know a lot" :)
But since the purpose of the articles and examples is to show the simplicity of creating and operating systems using libuniset2 , I will not go very deeply into the details. But the general principle will still have to be described ( although it was partially stated even in that first article ).
So that processes (uniset objects) can communicate with each other, they have a unique identifier (as part of the project), but this is not enough :) so that they can receive notifications from SharedMemory so that debugging tools can work with these objects, etc., they need to say something about themselves. For this is the repository. In general, this all goes back to the CORBA technology. In this case, libuniset2 uses the omniNames repository (name service) implementation , included in libomniORB ( AT & T's CORBA implementation ), for this.
And one more feature of local setup, which should be mentioned. Since A lot of developers can work on one project (on one server), and everyone wants to run their own copy of SharedMemory , processes, it is necessary to somehow separate them all among themselves. To do this, all instances of the processes run on different ports. And how to guarantee the uniqueness of the port for each user? In libuniset, we went the following way: we run processes on a port equal to USERID + 50000, in order to move all this into the “relatively secure” area that does not intersect with anyone. And all this is relevant only for local setup. Since in a real system (on the controller), the processes will already be running in a single copy.
All this debug binding is hidden in several uniset2-start.sh and uniset2-stop.sh scripts supplied with the libuniset2-utils package . Therefore, in order to run the simulator (and not to interfere with anyone), you must launch it using uniset2-start.sh . And in order not to write a string with keys each time, a file called start_fg.sh was created in the Imitator directory with the following contents:
The -f option means run the program in the foreground.
The uniset2-start.sh utility at startup just inserts the necessary parameters (- -uniset-port xxx ) for the shift of the port.
In addition, it starts the name service (repository) if it is not yet running. During operation (debugging), it is sufficient to start the name service ( omniNames ) once. Although apparently worth a little need to talk about it ..
The repository is a “program” that performs functions similar to a DNS server. In general, this is a name service for CORBA objects. If in a simple way, then each object is registered in the repository, publishes a CORBA link to itself under its (unique) name. After that, all who need to refer to this object, request a link by name from the repository and continue to work with this link. In general, the CORBA name service is a more complex topic (hierarchies and conglomerates can be built from them as well as from the DNS), etc. In our application, everything is simpler. OmniNames starts (this is actually the program repository). It runs on a specific port. The repository runs one for all current uniset-projects, and they do not interfere with each other, because Each project creates its own hierarchy of objects in it, starting from the root, which is called as a project, or rather specified in configure.xml by the parameter RootSection = ".." . In a real project, you can do without a repository, but remote access to the object will not be available.
The specifics of launching a uniset project is that “once” the repository structure for the project ... needs to be created. And for this is another special (multifunctional) utility - uniset2-admin
We will still use this utility for other purposes, but now we need to create a repository.
The complete command for this is:
But to facilitate this process, the source code contains the src / Services / Administator directory and there are “command links” for quick launch. There is also a " create " command. Run it and if all goes well, then we will not see any errors.
There is one detail, the scripts are designed for you to enter the src / Services / Administator directory and run create there (they just search for configure.xml in the current directory).
To check that the repository is created, you can (need) run the “ ./exist ” command in the same place and see the following
As can be seen from the output, uniset creates three sections in the repository Services , Controllers , Objects . Actually four, the fourth is sensors , but it is not visible here, we will work with it later :)
')
Before we launch the simulator, we need to launch the “repository” - SharedMemory . We have already created a repository, so just go to the src / SharedMemory / directory and start there start_fg.sh and then see it on the screen
To make sure that SM is available for work, move (in another console) to the src / Services / Administrator directory and run ./exist . We should see:
So everything is ok.
Finally run the simulator. As you can already guess, go to the src / Algorithms / Imitator directory and run ./start_fg.sh
To make sure that the simulator is already working ... move (in another console) to the src / Services / Administrator directory and run. / exist
So we have already launched SM and Imitator. This is enough to start debugging the simulator and use this example to see what tools are available for this. But still, before I describe the setup, we will create our main management process ... in the next part ...
For those who are interested:
Running simulator
With the launch on the one hand, everything is simple, but on the other hand there is some magic. She is quite understandable, if "know a lot" :)
But since the purpose of the articles and examples is to show the simplicity of creating and operating systems using libuniset2 , I will not go very deeply into the details. But the general principle will still have to be described ( although it was partially stated even in that first article ).
So that processes (uniset objects) can communicate with each other, they have a unique identifier (as part of the project), but this is not enough :) so that they can receive notifications from SharedMemory so that debugging tools can work with these objects, etc., they need to say something about themselves. For this is the repository. In general, this all goes back to the CORBA technology. In this case, libuniset2 uses the omniNames repository (name service) implementation , included in libomniORB ( AT & T's CORBA implementation ), for this.
And one more feature of local setup, which should be mentioned. Since A lot of developers can work on one project (on one server), and everyone wants to run their own copy of SharedMemory , processes, it is necessary to somehow separate them all among themselves. To do this, all instances of the processes run on different ports. And how to guarantee the uniqueness of the port for each user? In libuniset, we went the following way: we run processes on a port equal to USERID + 50000, in order to move all this into the “relatively secure” area that does not intersect with anyone. And all this is relevant only for local setup. Since in a real system (on the controller), the processes will already be running in a single copy.
All this debug binding is hidden in several uniset2-start.sh and uniset2-stop.sh scripts supplied with the libuniset2-utils package . Therefore, in order to run the simulator (and not to interfere with anyone), you must launch it using uniset2-start.sh . And in order not to write a string with keys each time, a file called start_fg.sh was created in the Imitator directory with the following contents:
#!/bin/sh uniset2-start.sh -f ./imitator The -f option means run the program in the foreground.
The uniset2-start.sh utility at startup just inserts the necessary parameters (- -uniset-port xxx ) for the shift of the port.
In addition, it starts the name service (repository) if it is not yet running. During operation (debugging), it is sufficient to start the name service ( omniNames ) once. Although apparently worth a little need to talk about it ..
Repository
The repository is a “program” that performs functions similar to a DNS server. In general, this is a name service for CORBA objects. If in a simple way, then each object is registered in the repository, publishes a CORBA link to itself under its (unique) name. After that, all who need to refer to this object, request a link by name from the repository and continue to work with this link. In general, the CORBA name service is a more complex topic (hierarchies and conglomerates can be built from them as well as from the DNS), etc. In our application, everything is simpler. OmniNames starts (this is actually the program repository). It runs on a specific port. The repository runs one for all current uniset-projects, and they do not interfere with each other, because Each project creates its own hierarchy of objects in it, starting from the root, which is called as a project, or rather specified in configure.xml by the parameter RootSection = ".." . In a real project, you can do without a repository, but remote access to the object will not be available.
The specifics of launching a uniset project is that “once” the repository structure for the project ... needs to be created. And for this is another special (multifunctional) utility - uniset2-admin
We will still use this utility for other purposes, but now we need to create a repository.
The complete command for this is:
uniset2-start.sh uniset2-admin --confile configure.xml --create But to facilitate this process, the source code contains the src / Services / Administator directory and there are “command links” for quick launch. There is also a " create " command. Run it and if all goes well, then we will not see any errors.
[pv@pvbook Administrator]$ ./create [pv@pvbook Administrator]$ There is one detail, the scripts are designed for you to enter the src / Services / Administator directory and run create there (they just search for configure.xml in the current directory).
To check that the repository is created, you can (need) run the “ ./exist ” command in the same place and see the following
Screen output
[pv@pvbook Administrator]$ ./exist ||=======******** UNISET-EXAMPLE/Services ********=========|| !!!!!! ||=======******** UNISET-EXAMPLE/Controllers ********=========|| !!!!!! ||=======******** UNISET-EXAMPLE/Objects ********=========|| !!!!!! [pv@pvbook Administrator]$ As can be seen from the output, uniset creates three sections in the repository Services , Controllers , Objects . Actually four, the fourth is sensors , but it is not visible here, we will work with it later :)
')
Run SharedMemory
Before we launch the simulator, we need to launch the “repository” - SharedMemory . We have already created a repository, so just go to the src / SharedMemory / directory and start there start_fg.sh and then see it on the screen
[pv@pvbook SharedMemory]$ ./start_fg.sh SharedMemory1(sysCommand): wait activate... ************************** activate: 1 msec To make sure that SM is available for work, move (in another console) to the src / Services / Administrator directory and run ./exist . We should see:
Screen output
[pv@pvbook Administrator]$ ./exist ||=======******** UNISET-EXAMPLE/Services ********=========|| !!!!!! ||=======******** UNISET-EXAMPLE/Controllers ********=========|| (22000 )SharedMemory1 <--- exist ok ||=======******** UNISET-EXAMPLE/Objects ********=========|| !!!!!! [pv@pvbook Administrator]$ So everything is ok.
Running simulator
Finally run the simulator. As you can already guess, go to the src / Algorithms / Imitator directory and run ./start_fg.sh
[pv@pvbook Imitator]$ ./start_fg.sh 04/03/2016 01:24:32( info): Imitator1(waitSM): waiting SM ready 60000 msec testID=101 04/03/2016 01:24:33(level8): Imitator1(resetMsg): reset messages.. To make sure that the simulator is already working ... move (in another console) to the src / Services / Administrator directory and run. / exist
Screen output
[pv@pvbook Administrator]$ ./exist ||=======******** UNISET-EXAMPLE/Services ********=========|| !!!!!! ||=======******** UNISET-EXAMPLE/Controllers ********=========|| (22000 )SharedMemory1 <--- exist ok ||=======******** UNISET-EXAMPLE/Objects ********=========|| (20001 )Imitator1 <--- exist ok [pv@pvbook Administrator]$ So we have already launched SM and Imitator. This is enough to start debugging the simulator and use this example to see what tools are available for this. But still, before I describe the setup, we will create our main management process ... in the next part ...
For those who are interested:
Source: https://habr.com/ru/post/278537/
All Articles