hellocore

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
hellocore [2016/04/26 14:35]
mroriz
hellocore [2017/07/21 03:08] (current)
Line 38: Line 38:
 </code> </code>
  
-We will make the connection with the gateway in our constructor. The client connection is very straightforward; first, we create a ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnclib/net/mrudp/MrUdpNodeConnection.html|MrUdpNodeConnection]]'' object. This connection object, encapsulate the details and protocol involved in the physical connection with the gateway, for instance, it uses unique ids to identify the client and the connection when the node changes IPs. If we do not specify an argument in the connection instantiation, it automatically generates an UUID to identify the client. As you have read in the [[Basic|basic concepts]], this id is used to unique identify the client independent of his IP, which is useful for handover and abstracting the client location. After creating the object, we establish the connection calling the ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/lac/cnclib/net/mrudp/MrUdpNodeConnection.html#connect(java.net.SocketAddress)|connect()]]'' method passing the gateway ''address'' as parameter. Finally, we add our object as a ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnclib/net/NodeConnectionListener.html|NodeConnectionListener]]'', this listener holds methods related to the node gateway connection. It will trigger functions to indicate that the node has successfully connected, disconnected, reconnected from the gateway alongside with operations to receive new messages, and unsent messages (messages that were timeouted and not sent due to disconnection).+We will make the connection with the gateway in our constructor. The client connection is very straightforward; first, we create a ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnclib/net/mrudp/MrUdpNodeConnection.html|MrUdpNodeConnection]]'' object. This connection object, encapsulate the details and protocol involved in the physical connection with the gateway, for instance, it uses unique ids to identify the client and the connection when the node changes IPs. If we do not specify an argument in the connection instantiation, it automatically generates an UUID to identify the client. This id is used to unique identify the client independent of his IP, which is useful for handover and abstracting the client location. We add a listener to the connection object (''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnclib/net/NodeConnectionListener.html|NodeConnectionListener]]'')which provides methods to react to the node gateway connection. It will trigger functions to indicate that the node has successfully connected, disconnected, reconnected from the gateway alongside with operations to receive new messages, and unsent messages (messages that were timeouted and not sent due to disconnection). Finally, we establish the connection calling the ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/lac/cnclib/net/mrudp/MrUdpNodeConnection.html#connect(java.net.SocketAddress)|connect()]]'' method passing the gateway ''address'' as parameter
  
 <code java> <code java>
Line 113: Line 113:
       try {       try {
           connection = new MrUdpNodeConnection();           connection = new MrUdpNodeConnection();
-          connection.connect(address); 
           connection.addNodeConnectionListener(this);           connection.addNodeConnectionListener(this);
 +          connection.connect(address);
       } catch (IOException e) {       } catch (IOException e) {
           e.printStackTrace();           e.printStackTrace();
Line 154: Line 154:
 </file> </file>
 ==== Processing Node ==== ==== Processing Node ====
-The core nodes establishes premises and protocols that are not suitable for mobile applications. To expand this processing power to mobile nodes, we added the concept of gateways that use our lightweight protocol to communicate with mobile nodes and translate their message to core messages. Developers can instantiate nodes to process the mobile nodes message.  +The core processing nodes establishes premises and protocols that are not suitable for mobile applications. To expand this processing power to mobile nodes, we added the concept of gateways that use our lightweight protocol to communicate with mobile nodes and translate their message to core messages. Developers can instantiate nodes to process the mobile nodes message.  
  
-To create our processing node application, create an empty Java ''HelloCoreServer'' Class using thebr.pucrio.inf.lac.helloworld package. You can create this class in the existing ''HelloCore'' project or create a separated project, for now we will make the class in the existing project. The processing nodes communicate using [[SDDL]], an abstraction that encapsulate the [[wp>DDS|DDS]] communication. +To create our processing node application, create an empty Java ''HelloCoreServer'' Class using the ''br.pucrio.inf.lac.helloworld'' package. You can create this class in the existing ''HelloCore'' project or create a separated project, for now we will make the class in the existing project. The processing nodes communicate using [[SDDL]], an abstraction that encapsulate the [[wp>DDS|DDS]] communication. 
  
 The processing node uses the DDS protocol to communicate in the core. Thus, it needs to create readers and writers to manipulate data in the core. In addition, it needs to formally join the other core nodes, this is done by recovering an instance of the middleware and creating a participant. After that, it instantiate publishers and subscribers to enable reading and writing data. In our application, we are interested in reading the application messages sent to the core, thus, we create a data reader for the ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnet/sddl/objects/Message.html|Message]]'' topic, which represents application messages. We are also interested on sending a reply to our mobile node, thus, we create a data writer for the private message topic, which allow us to send a message to a specific node. Our processing node will count the number of messages received, thus, we define a global count variable. Finally, we specify a very simple wait command to ensure that the processing nodes stays alive. This initial code is displayed bellow: The processing node uses the DDS protocol to communicate in the core. Thus, it needs to create readers and writers to manipulate data in the core. In addition, it needs to formally join the other core nodes, this is done by recovering an instance of the middleware and creating a participant. After that, it instantiate publishers and subscribers to enable reading and writing data. In our application, we are interested in reading the application messages sent to the core, thus, we create a data reader for the ''[[http://www.lac.inf.puc-rio.br/dokuwiki/api/index.html?lac/cnet/sddl/objects/Message.html|Message]]'' topic, which represents application messages. We are also interested on sending a reply to our mobile node, thus, we create a data writer for the private message topic, which allow us to send a message to a specific node. Our processing node will count the number of messages received, thus, we define a global count variable. Finally, we specify a very simple wait command to ensure that the processing nodes stays alive. This initial code is displayed bellow:
Line 185: Line 185:
  
     counter = 0;     counter = 0;
 +    System.out.println("=== Server Started (Listening) ===");
     synchronized (this) {     synchronized (this) {
       try {       try {
Line 239: Line 240:
  
     counter = 0;     counter = 0;
 +    System.out.println("=== Server Started (Listening) ===");
     synchronized (this) {     synchronized (this) {
       try {       try {
Line 272: Line 274:
 To execute our application, we need to first create the gateway, which will instantiate the core infrastructure if none exists. The gateway receives two parameters, its public IP and a given port number. Since we are this sample locally, we can choose the loopback IP ''127.0.0.1'' and the default middleware port ''5500''. To do that, open a shell, and run the following command: To execute our application, we need to first create the gateway, which will instantiate the core infrastructure if none exists. The gateway receives two parameters, its public IP and a given port number. Since we are this sample locally, we can choose the loopback IP ''127.0.0.1'' and the default middleware port ''5500''. To do that, open a shell, and run the following command:
  
-  $ gateway 127.0.0.1 5500 OpenSplice+  $ java -jar contextnet-2.5.jar 127.0.0.1 5500 OpenSplice
  
 After that, we instantiate our processing node. To do that, run the ''HelloCoreServer'' class in Eclipse as a Java application. Finally, execute the ''HelloCoreClient'' class in Eclipse to start the mobile node application. You will see the printed messages in your console. After that, we instantiate our processing node. To do that, run the ''HelloCoreServer'' class in Eclipse as a Java application. Finally, execute the ''HelloCoreClient'' class in Eclipse to start the mobile node application. You will see the printed messages in your console.
 +
 +===== Final Remarks and Extending This Example =====
 +This tutorial demonstrated how to connect a mobile node with the core processing nodes in the ContextNet architecture. The example used a basic code that illustrates the asynchronous send and receive primitives for both, the client and core, type of nodes. As an exercise try to extend the client node application to send several messages and use several core servers.
  • hellocore.txt
  • Last modified: 2017/07/21 03:08
  • (external edit)