Using Opnet Modeller for the Delivery of the COPAR Service and Improved Availability on the
Internet
Rhea L. Seegobin, The University of the West Indies, St. Augustine, Trinidad, [email protected] Michael A. Hosein, The University of the West Indies, St. Augustine, Trinidad, [email protected]
Abstract- The COPAR service is a Java based distributed system that runs over the Internet. The system works by replicating data at separate sites using optimistic and pessimistic processing techniques. The aim of COPAR is to test the availability and scalability of a system when expanded. Improvements on this project have been outlined in several papers ([2], [3], [4], [5], [6] and [12]). Limitations were encountered for the expansion of COPAR. Resources needed to host 20 or even 40 nodes were very costly to attain. Opnet which is trusted by global electronic manufactures, eliminates these limitations by simulating a virtual environment.
Opnet was used to expand COPAR from 8 nodes to 100 nodes. This paper outlines the implementation details for the conversion of COPAR from a Java-based implementation to an Opnet simulation. This paper focuses on the OPNET editors employed to facilitate this implementation, the transaction generator’s node and process model and a
server’s node and process model. This paper can be particularly helpful to future researchers that want to improve and expand COPAR even further, using Opnet Modeler. It can also be useful to researchers that want to create simulations using C++ with similar implementation styles.
The COPAR (Combining Optimism and Pessimism in Accessing Replicas) system was implemented in Java and ran on eight (8) distributed nodes, connected to each other via the Internet. Nodes were hosted at Rowan University, in Glassboro New Jersey, USA and the University of the West Indies, St. Augustine. In the previous COPAR Service there were three main objects used for processing, the ServerImpl object, PermanentProcessor object and the TemporaryProcessor object. The ServerImpl object acted as a server object which was responsible for processing a transaction optimistically (temporarily) at a local node. The transaction was then transferred to be processed
optimistically at all other remote server nodes. The Temporary Processor object performed this optimistic processing while the PermanentProcessor object performed pessimistic (permanent) processing.
COPAR uses a cost bound variable when processing these transactions. The cost bound in COPAR refers to the number of resources available for distribution in the system. A transaction is committed only if the cost bound for the entire system is not violated. The cost bound formula developed by Crichlow [2] was implemented in the previous version of COPAR, to manage the distribution of such resources. The cost bound formula was also used to determine whether or not a transaction would be processed successfully and committed, or if the transaction would be rejected and undone. The cost bound resource was increased as the number of transactions and nodes in the system was increased.
Some of the challenges encountered when attempting to expand the original COPAR system were human resources, number of available servers and funding. The overall resources required to facilitate the participation of 100 physical servers at differing geographical locations, was deemed infeasible. This was one of the reasons why Opnet Modeler was chosen, the only cost involved was the actual cost of the simulation software (Opnet) and the computer used. OPNET Modeler is a simulation package used to build and test network models. It was originally developed at the Massachusetts Institute of Technology (MIT) and was introduced in 1987 as the first commercial network simulator. Opnet Modeler is used to design communication networks, products, technologies, and protocols. Opnet’s [7] cutting-edge technology enables innovation and allows users to:
• Design new protocols and technologies as well as
evaluate changes to existing ones • Test and demonstrate designs in realistic scenarios
before production • Optimize protocol and application performance • Plan mobile network deployments that accurately
DOI: 10.5176/2251-3043_3.4.293
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
incorporate terrain effects and wireless propagation impairments.
Some of the advanced features of Opnet Modeler used in this project are object-oriented modeling, code optimization, parallel C++ thread implementation, integration of external C++ objects, statistic recording, transaction generation and the reuse of model objects.
There exist three main editors that encompass the modeling architecture of Opnet Modeler: the network editor, the node editor and the process editor. The network editor is used to represent the topology of
the network. The node editor is used to depict the flow of data
between network topology elements. The process editor defines the behavior of a node
through the use of a finite state machine.
These editors allowed the conversion of Java classes into node and process models in the Opnet simulation. During this conversion, all efforts were made to ensure that functionality was not compromised. This paper outlines the components of Opnet and how they were used to maintain the original functionality of the system. It also shows how the main Java classes: Transaction Generator, ServerImpl, TemporaryProcessor and Permanent Processor were implemented in Opnet. The Transaction Generator class was implemented as a transaction generator node and process model, while the functionality of the other three (3) main classes were merged and implemented in a server node with its own process model. This paper also explains how the model of the server object was reused in COPAR. This facilitated an easy expansion to the number of server nodes with minimal effort.
2. Editors and Components used to implement the COPAR Service in Opnet Modeler
Opnet provides three main editors which were used for the implementation of the COPAR Service in Opnet. These editors are: the Network, Node and Process editors. The Network editor is contained in the Network domain, the Node editor is contained in the Node domain and the Process editor is contained in the Process domain. The network, node and process domains are hierarchically related to each other. The objects in the process domain are used to build process models which simulated the behavior of nodes in a simulation. Process models are instantiated in the Node Domain, which creates node models. The node models are then instantiated in the Network Domain to create a functional OPNET project. The network editor is used to design the physical topology of a communication network. This editor works at the highest level and it uses objects that are defined at the lower levels of the hierarchy. The Network editor uses objects such as subnets, fixed/mobile nodes, communication links (FDDI, simplex or duplex), desktops, servers, routers and many more.
The node domain consists of nodes that contain process models, transmitters, receivers, packet streams and point-to-point links. A node in Opnet is synonymous to an actual computer that would have been used in the expansion of the Java-based version of COPAR. A node is capable of generating and sending data to other nodes using transmitters. A node can also receive and process data from other nodes using receivers. The nodes for COPAR were programmed to send and receive data packets similar to the Internet. The nodes are also capable of routing incoming packets to specific processes, processing and storing data, processing signal interrupts and implementing priority settings. A packet stream acts as a port number, which is used to deliver the packet to the correct process. Point-to-point links act as physical media that connect computers together in a LAN or WAN.
Process models were used to give the nodes similar behaviors to the original Java version of COPAR. The TransactionGenerator class has now been implemented in Opnet using a node and a process model. Some functions of the TemporaryProcessor and PermanentProcessor classes have been implemented in the server’s node and its process model. The process models for this project used child thread processes, header files, external class files, functions, forced states, and unforced states to replicate the functions of the previous system.
Process models are capable of creating multiple child processes that run in parallel to the main process. Related processes in Opnet can communicate with one another using process interrupts and message passing. Opnet Modeler allows external C/C++ files to be imported into the header files of a process model. The process editor also allows externally declared class files and packet formats to be imported into a process model.
The function block of a process model is where all functions are implemented. Function prototypes are declared in the header block of a process model. Function names should be unique throughout the entire simulation because they can be seen by all process models. The functions in the function block were written with a combination of Opnet and C/C++ programming languages.
Transitions were used to order the flow of execution within a process model. Transition objects were altered to wait for specific interrupts or follow default transitions. A transition object is synonymous to ‘if’ and ‘else’
statements, as it determines the course of action that should be taken for different conditions. An interrupt was used to signal the process model to execute specific code residing in the state to which the transition object was attached.
The link editor was used to create the different types of communication links. There are many types of communication links: simplex, duplex and FDDI. The duplex link model was used for the new implementation of COPAR. One link object was created and reused to connect all nodes together in the COPAR simulation. A link object can specify the rate of data that can be transferred, the expected delay and the types of data packets (new and existing) that can be sent along the links.
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
Packet streams are physical connections that support the transfer of packets among modules, within the same node. Packet streams allow the movement of a packet from a receiver module to a node’s processor module. A packet
stream must be connected to the output port of a source module and the input port of a destination module, for the transfer of data to be successful. These ports are referred to as the source module's output stream and the destination module's input stream. There can be multiple input and output packet streams attached to a processor module. In the Transaction Generator process model there were many pairs of transmitters and receivers attached to the transaction generator processor. Each transmitter and receiver pair was used to send packets to different server nodes in the simulation. In the server model there was only one transmitter and receiver attached to the processor in that process model.
Interrupts assists in modeling event driven executions. For example, when a packet is delivered to a node model, a specific type of interrupt signal is raised for the process to perform a specific type of action. This project uses forced interrupts for all nodes in the simulation. A forced packet delivery interrupt suspends the process model’s
current execution and immediately attends to the interrupt. The process model then executes the action needed and when it is finished, the process continues its execution from where it was suspended by the interrupt.
Nodal and process priorities can be used to order the flow of events in a network model. The process and node priorities are not the same; node priorities have precedence over process priorities. Priorities were set to allow initialization of all main objects and data types before transaction generation for the system commenced. The process priorities for all server nodes were the same; however, the node priority for each server node was different. The priority settings for the server nodes were higher than the priority settings for the transaction generator node. This helped to ensure that all main objects were initialized and the servers were up and ready to receive incoming transactions.
There were three (3) different types of variables used in COPAR Opnet: temporary, global and state. The majority of variables implemented in the new COPAR simulation were state variables. The four main reasons for using state variables in the simulation are:
1. State variables maintain their memory from invocation
to invocation throughout the simulation.
2. State variables are accessible in function blocks as opposed to temporary variables.
3. State variables can be passed as parameters to threads
functions.
4. State variables can be used to obtain references to remote objects, as seen in [6].
3. Implementation of COPAR’s Main Classes in Opnet Modeler
The main classes that perform the majority of
processing activities are the transaction generator class, server implementation class, temporary processor and permanent processor classes.
In Opnet the transaction generator class was converted into a single node and process model. The transaction generator process model consists of three forced states, with each state being mapped to one major function in the previous COPAR system. The first state, TransGenerator, read from the input files and initialized the server and server ratio vectors, which were used for the random distribution of transactions. The second state, startGeneration, performed the same function as the previous system, which generated transactions and sent it to servers based on the server ratios. The third state, remote_interrupt, was used to check when all the transactions were finished processing. Functions from the ServerImpl class such as seeIfDone() and terminate() were also implemented in the remote_interrupt state of the transaction generator process model. It polled each server in a sequence to check if all transactions were finished processing and if not, the main process slept for 20 seconds. The simulation ended automatically, when all the transactions were processes temporarily and permanently.
The server process model contained a number of functions from the previous ServerImpl, TemporaryProcessor and PermanentProcessor classes. These classes performs it previous operations with help from the server node. Each server node is an exact replica of the other, except that they have unique names. All the server node models are set to use the same server process model. This adheres to a proper object oriented design and facilitated a manageable expansion to the number of server nodes present in the simulation.
In the Opnet implementation of COPAR, there still exists a class for the main ServerImpl object with less functionality. Some changes have been made to this main class. The constructor method in the ServerImpl Java class has now been implemented in the initialize state of each server’s process model. There is a new function in the ServerImpl class that adds incoming transactions to the parent queue and a new incoming_queue queue, instead of childq0 queue. This facilitated faster processing of incoming transactions.
A TemporaryProcessor class is still used in the new implementation of COPAR, however not all class functions remained defined in this class. The function run(), a previous class function, was implemented in the function block of each of the server node’s process model, called
TemporaryProcessorThread(). The previous TemporaryProcessor class did not extend any threading characteristics. There were two threads created and managed by each server’s process model: one for optimistic processing and the other for pessimistic processing. The function TemporaryProcessorThread()
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
was used by a server thread to perform optimistic processing.
Similar changes were made to the class PermanentProcessor. The PermanentProcessor function run(), was also implemented as a function in the function block defined in each of the server node’s process model. The name of the function is was changed from run() to PermanentProcessorThread(). The class implementation of the PermanentProcessor object does not extend any threading characteristics either. The new function PermanentProcessorThread() was used by the permanent processing thread to perform pessimistic processing.
4.1 Transaction Generator Node Model The transaction generator is responsible for generating and delivering a transaction to a random server for processing. A number of links connect the transaction generator node to every server node in the simulation. There is a maximum of 100 nodes in the simulation and as a result, 100 pairs of transmitters and receivers were created in the transaction generator node model, seen below in Figure 1. There were also 200 packet streams created for connecting the transmitters and receivers to the processor of the transaction_generator node model.
Figure 1. Transaction Generator Node Model
The outgoing packet streams (connected to the transmitters) were all set to signal a forced interrupt at the remote server node to which the data packet was sent. A forced interrupt signals a process to suspend its current course of action and attend to the interrupt immediately. When the process is finished processing the interrupt, it continues from where it was paused. This was done in order to retrieve incoming transactions immediately. This means that the packet will be placed in a transaction queue as soon as it is received. This does not guarantee that the transaction will be processed immediately.
In the transaction generator node there is a matching transmitter and receiver for every server. Each server node contains a designated transmitter and receiver used to retrieve a transaction that was send by the transaction generator node model.
4.2 Transaction Generator Process Model The transaction generator process model is the equivalent of the Java TransactionGenerator class in the previous COPAR implementation. It consists of forced and unforced states, where green states represent forced states and red states represent unforced states. There are three forced states which execute consecutively until the final idle unforced state is reached, as seen below in Figure 2.
Figure 2. Transaction Generator Process Model
This process model uses the newly created header and external C++ files in order to maintain the same functionality as the original system did. The TransGenerator state performed initialization of objects needed for the simulation. In the startGeneration state, the transactions were created and sent to the remote servers for processing. The contents of the packets sent from this module consisted of a transaction_id, a transaction_change and a transaction_code. When a transaction was sent to a remote server, the transaction generator’s process would be paused for the duration specified in its input file (either 5 or 10 seconds). This sequence of events was repeated in the startGeneration state, until all the transactions were generated and sent to the remote servers. The process then moved onto the next state in the process model, the remote_interrupt state.
The remote_interrupt state issued a remote interrupt to each server node, signaling that it has finished its transaction generation. The remote_interrupt state also checked to see if the remote servers were finished processing all of the transactions pessimistically. If the remote server node was not finished, the transaction_generator process would sleep periodically for 20 seconds until all parent transactions were processed at that server. When a server processed all the parent transactions, control was returned to the transaction_generator process model. The
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
transaction_generator module then checked the next consecutive server to see if it was finished processing its share of the parent transactions. This sequence of events continued until all the servers were finished processing the parent transactions, after which the simulation came to an end.
5.1 Server Node Model The node model shown below in Figure 3 was replicated for all server nodes. It consisted of a processor, a transmitter and a receiver. The receiver is attached to the processor via a packet stream. The packet stream is set to receive forced interrupts from the transaction generator node and process model. When the transaction generator node sends a transaction to the intended server’s node, the
server node’s process is immediately signaled using a forced interrupt, indicating that a packet was received.
Figure 3. Server's Node Model
If the interrupt is a scheduled interrupt, the incoming packet will be stored in the processor’s incoming queue
until the server checked its queue at a scheduled time, e.g. every ten seconds. Since this node model was designed using forced interrupts, the packet was immediately moved from the input packet stream to the receiver processor, shown above in Figure 3 and subsequently to the state ‘process_interrupt’ in the process model, seen below in Figure 4.
5.2 Server Process Model
This server process model is responsible for processing incoming transactions sent from the transaction generator. The green state initialize, shown below in Figure 4, was executed at the start of the simulation. It creates the local objects ServerImpl, TemporaryProcessor, PermanentProcessor and then took the default transition to move onto the process_interrupt state, where it waited for an incoming packet interrupt from the transaction generator node.
Figure 4. Server's Process Model
When a packet is received at a server, the transition
labeled (PK_ARRVL)/route_pk(my_server_impl) becomes true and the function route_pk(my_server_impl) as well as state process_interrupt, are executed. The function routine route_pk(my_server_impl) added the incoming transaction to its parent and incoming_queue queues. When the process_interrupt state finishes its execution, it takes the default transition attached to itself and waits for another interrupt to be raised by another incoming transaction. When the transaction generator generates all the transactions for the simulation, it signales a remote interrupt to every server, causing the transition PK_END to be taken and the state close_file to be executed.
The purpose of the close_file state shown below in Figure 4, is to check if all local parent transactions are processed, and if not, the process repeatedly sleeps for 20 second intervals, until all parent transactions are processed. The contents of the result_list and image_list for each server are then written to output files. This state is similar to the remote_interrupt state in the transaction generator process model as it enforces redundant checks for the processing of all parent transactions.
6. Assignment of Process and Node Priorities
All process priorities for server nodes were set to one, because they all have the same performance capabilities. If server node A has a process priority of one (1) and server node B has a process priority of two(2), then the process model at node B would be given more processing time over node A. This is why all server nodes were given the same process priority. The transaction generator node was assigned a lower process and node priority to ensure that all server nodes were up and running, ready to receive incoming transaction from the transaction generator.
The node priorities implemented in the simulation permitted each node to commence processing in a
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
sequential manner. The node with the highest node priority began to execute first. Then the node with the next highest node priority would start its execution. This sequence of events continued until all the server nodes completed their initialization phase. The initialization phase in each server node created the ServerImpl, TemporaryProcessor and PermanentProcessor objects. The transaction generator node was the last node to begin processing since it had the lowest priority settings. The order of the server node priorities does not matter, as long as all the server nodes carry a higher priority than the transaction generator node.
7. Global Statistics and Statistic Handles
Two (2) global statistics were used for recording permanent and temporary response times for each transaction: temp_response_time and perm_response_time. Global statistics can be defined in any node in the simulation. A global statistic is similar to an array data structure. In the Opnet implementation, the statistics were defined in the transaction generator’s
process model. A statistic handle is required for data to be written to a global statistic.
The TemporaryProcessor and PermanentProcessor objects were responsible for writing each transaction’s
response time to the global statistic. Each server node had its own TemporaryProcessor and PermanentProcessor object; therefore each object had to create its own statistic handles in order to write to the global statistic.
The variables temp_response_time and perm_response_time were used to generate the output graphs for the simulation. These statistics recorded the response time for each transaction processed optimistically and pessimistically. The graphical output can be seen in [6].
8. Execution Sequence for the COPAR Service in
Opnet
When the simulation commenced, the following sequence of events occurs: 1. Each server executes the initialize state of each process
model, where all servers and thread objects are initialized and created. The thread processes are created and then the process model goes into a suspended state to await transactions from the transaction generator node.
2. The server with the next highest node priority performs
the same function as step 1. Steps 1 and 2 are executed continuously until all server objects and threads, are initialized and reach a suspended state.
3. When all servers are up and running, the transaction generator begins to generate and send transactions to random servers based on server ratios.
4. When a transaction is received by the server, a receive packet interrupt signals the server’s process model,
which was in a suspended state, to take the necessary action for the interrupt it has just received. In this case it received a forced interrupt, causing the server process model to call the storeIncomingTransaction() function in the ServerImpl class. The server process then goes back into a suspended state, to await another incoming transaction from the transaction generator. It should be noted that the temporary and permanent threads for all nodes execute simultaneously with the parent process. This means that even though the server process model is suspended the thread processes are still running.
5. The transaction generator regains control and continues
to generate and send transaction. Steps 4 and 5 are executed continually until all transactions have been generated.
6. The transaction generator then moves onto the third state
where it polls each server sequentially to check if permanent processing is finished. When a server finishes processing all its transactions, it prints out the child queues and the results queues to individual output files and returns control to the transaction generator node. When all the servers are finished printing the contents of the vectors, the simulation comes to an end.
9. Adding Server Nodes to the COPAR Service in
Opnet Modeler The COPAR Service was implemented in five project sizes using Opnet Modeler. The number of nodes in the simulation was 20, 40, 60, 80 and 100 nodes maximum. These sizes were incrementally increased to test how well the system scaled and if the availability of the system was maintained. Scalability and availability can be referenced in [6].
A series of steps to increase the number of servers in the simulation were developed and employed. Since the simulation only had one transaction generator node, these steps only applied to a server node. To add a new server node to the simulation these steps needed to be followed: 1. Create a copy of an existing server node model and
give it a unique name. Then import the process model COPAR_transaction_receiver_model into the node model to give the node its behavior. Remember, all server nodes use the same server process model.
2. Assign the node and process priorities and enable the
begin simulation interrupt variable for the node. This allows for a correct initialization sequence.
3. Set the incoming packet stream in the new server node
model to generate a ‘forced’ interrupt when a packet is received.
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
4. Create a new server input file for the new server node. 5. Change the main input file ‘input file.txt’ to include
the name of the new server node, the server ratio and change the ‘number of servers’ parameter to include the new server.
6. Change all the Continental_xxxx.txt files to reflect the
inclusion of the new server node, i.e. number of servers, server’s name and the continental code.
7. Open Opnet’s object palette and drag the newly
created server node onto the network map.
8. Set the ‘name’ attribute of the server node. Set the
server’s model attributes for the respective input files. 9. In the transaction generator process model, create a
new transmitter and receiver to communicate with the new server node. The transmitter and receiver should be connected to the model’s processor object via
packet streams. Set the outgoing packet stream to signal a ‘forced’ interrupt at the server node.
10. Create a new link between the transaction generator
node and the new server node. This is done by ‘Right
clicking’ on the link, editing the attributes and setting
the transmitters and receivers for the new link. 11. Select the ‘Topology’ option in the project menu and
select the option ‘verify link’. This ensures that the
new link is correctly activated. If a red X appears on the communication link, one has to check that the correct transmitter and receiver are assigned to the link.
This sequence of steps can be followed repetitively to include any number of server nodes in the simulation, making the simulation easy to expand.
10. Conclusion
This paper outlines how the COPAR Service was converted from a Java-based Internet application to a simulation in Opnet Modeler. The major advantage of using Opnet is that it saves both time and money. The developers can now coordinate simulation runs at their own convenience without having to worry about different time zones and lack of human resources. Opnet was chosen because it is reliable and has been trusted by some of the world’s leading electronic manufacturers.
This paper examined the components of Opnet that were used to aid in the conversion and provide similar functionality as the previous system did. The simulation’s
editors (network, node and process) were used to mimic actual nodes that would have been running on the Internet. Client and server nodes were created and designed to behave similar to the original system.
The design of the main classes (ServerImpl, TemporaryProcessor, PermanentProcessor and TransactionGenerator) in the original system, were changed and discussed in this paper. The transaction generator class was completely changed from a class file to a node and process model. The three remaining classes were implemented in a combination of external header files, external class files, node models and process models. Output for the system was automatically generated using graphs and global statistics were written to output files upon completion of the simulation. The research developed for the expansion and the implementation of the system can be helpful to future researchers who wish to develop the system even further. Future work would involve examining the effects of wider node deployment on performance.
References
[1] Microsoft Coporation 2010. http://msdn.microsoft.com/en-us/library/default.aspx (accessed 10 20, 2010).
[2] J.M. Crichlow, S. Hartley, M. Hosein, C. Innis, The COPAR Service: Combining Optimism and Pessimism in Accessing Replicas. Proceedings of the Third IASTED International Conference Communications, Internet and Information Technology. St. Thomas, US Virgin Islands: ACM, 2004. 558-563.
[3] J. M Crichlow, Combining Optimism and Pessimism to Produce High Availability in Distributed Transaction Processing. ACM SIGOPS Operating Systems Review, by J.M. Crichlow, 43-64. ACM, 1994.
[4] M.F. Fransis, J.M. Crichlow, A Mechanism for Combining Optimism and Pessisism in Distributed Processing. Proceedings of the IASTED/ISMM International Conference of Intelligent Information Management Systems. Washington D.C, 1995. 103-106.
[5] M. Hosein, J.M Crichlow, Fault-tolerant Optimistic Concurrency control in a Distributed System. Proceedings of the IASTED International Conference on Software Engineering. Las Vegas, October 28-31,1998. 319-322.
[6] R. Seegobin, M. Hosein, Expanding the COPAR Service using Mutual Exclusion, Optimization and C++ Threads in Opnet Modeler. Proceedings of the IASTED International Conference on Parallel and Distributed Computing and Networks. Innsbruck, Austria, February 15-17, 2011. 99-106.
[7] Inc., Opnet Technoligies. Opnet Modeler Accelerating Network R & D. 1986-2008. Opnet Technoligies Inc., 2011.
[8] S. Oaks, H. Wong, Java Threads Understanding & Mastering Concurrency Programming. O'reilly Media Inc., 2004.
[9] Verizon. 2011. “Verizon.” (accessed April 4, 2011) http://www.verizonbusiness.com /about/network/latency.
[10] Kernen, Thomas. 2011. http://www.traceroute.org. (accessed April
11, 2011).
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
[11] The C++ Resources Network. 2000-2010. http://www.cplusplus.com/ (accessed 10 20, 2010).
[12] R. Seegobin, M. Hosein, J. Crichlow, S. Hartley Design Changes to the COPAR Service using Opnet Modeler. Proceedings of the IASTED International Conference on Software Engineering and Applications. Dallas, USA, December 14-16, 2011.
Dr. Michael Hosein is currently a lecturer in the Department of Computing and Information Technology at The University of the West Indies, where he lectures mainly in the areas of wireless and mobile computing, distributed systems, computer networks, networking technologies, and computer programming. For many years he has taught the course “Wireless and Mobile Computing” in which
wireless apps are developed. He is also involved in app development using Bluetooth. Dr. Hosein is involved in examining duties for CAPE Computer Science of the Caribbean Examinations Council and is the coauthor of a CSEC Information Technology Multiple Choice Text. He has supervised students pursuing Masters and Ph.D. degrees. Mrs. Rhea Seegobin is currently a Ph.D. student in the Department of Computing and Information Technology at the University of the West Indies (UWI). She has taught several courses at the department especially a few that involve networking concepts. Rhea holds a BSc in Computer Science and an M.Phil. Computer Science with high commendation. Her main areas of research are network simulations and wireless application technology.
GSTF International Journal on Computing (JoC) Vol.3 No.4, April 2014
This article is distributed under the terms of theCreative Commons Attribution License whichpermits any use, distribution, and reproductionin any medium, provided the original author(s)and the source are credited.
