{'fraction_non_alphanumeric': 0.02449434032287994, 'fraction_numerical': 0.00037112636852848393, 'mean_word_length': 5.195402298850575, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
THE REMOTE OMNET + + DISTRIBUTED DISCRETE EVENT SIMULATION ENVIRONMENT

In this paper we present a remote simulation environment. Remote simulation makes it possible to share simulation resources among many users. Additional benefits include easy maintainability, model and data consistency. The novelty of our system is platform independence, easy applicability to different simulators. This system can be useful for universities for educational and resource purposes and even for engineer teams with simulation needs. INTRODUCTION Simulation plays an important role in everyday engineering. In some cases, it is impossible to provide an analytical solution to a problem. Hence the need for simulation, which yields acceptable solutions within predefined limits of accuracy. This is why the typical models used in simulation tend to be very complex. Obviously, simulating a large model requires a large amount of memory and calls for the greatest available processing power [1]. Ideally, simulation should be performed using machines that represent the state of the art in computer technology. However, if many engineers at a company or institution have daily simulation needs, upgrading each desktop workstation regularly would be expensive, or downright impossible. A solution for this problem can be remote simulation. Remote simulation means that the actual simulation is not performed on the user’s workstation. Instead, dedicated simulation execution servers are used for this purpose, which users can access through a computer network. In such a scenario, the users’ workstations can be regular desktop computers, without the need for huge processing power. An additional benefit of such a scheme is that it simplifies software upgrades, as the simulation engine resides on the server. In our paper we present a remote simulation environment, called Remote OMNeT++. OMNeT++ (Objective Modular Network Testbed in C++) is a Discrete Event Simulator developed at our university. It is used by many research groups for communication network performance estimation. In the Remote OMNeT++ system models and simulation results can be stored on a separate server, which reduces the risk of inconsistency within a team working with the same models, and eliminates the need for large data storage capacity at user workstations. ARCHITECTURE In this section the architecture of the Remote OMNeT++ system will be introduced. Further details about the architecture can be found in [2]. Functional separation In a simulation system, three functions can be clearly separated: • Control: Functions related to deploying, configuring, starting, stopping, monitoring a simulation, and evaluating the results . • Execution: Functions for executing the simulation using a simulation engine. • Storage: Functions for storing simulation models and simulation results. The above three functions can be separated in both time and space. Separation in time is rather trivial and automatic: control is not a time-consuming task, while functions related to execution and storage occur one after another. For example, the simulation model is retrieved from the storage for execution, and the results are transferred back to the storage. Spatial separation, on the other hand, is less obvious. It means not only separating these functions, but also concentrating resources on one or more servers with ample capacity to serve many users at a time. As we mentioned earlier, resource concentration can be useful for several reasons: • hardware costs • data consistency • software upgrade and maintenance Relative hardware costs can be reduced by increasing hardware utilization. Simulation is a typical example of a bursty load in terms of processor usage. While running, it requires as much processor power as possible, while model development or result analysis mean very little processor load. This means that by centralizing processing power, and making it available to many users at a time, processor utilization can be maximized. Ensuring data consistency is very important if a team is working together on the same model or set of models. Data in this context means models, model parameters and simulation results. If data storage is centralized, data can be more easily kept consistent. Sometimes it is necessary to upgrade the simulation engine or some other parts of the simulation system. If the simulator is installed on each user workstation, this upgrade can be cumbersome. This is especially true if upgrade means recompiling the simulation kernel, as it is the case with many Unix-based simulation systems. In a system with centralized resources such upgrades can be performed a lot more easily, because only the central simulation server has to be upgraded. Components Based on the above considerations, the architecture for our remote simulation system has been built around three basic components: • Client: The component that allows individual users to control the rest of the simulation system. • Processing Host: High-performance simulation execution server running the simulation engine. • Data Warehouse: A server with large storage capacity for storing simulation models, results, parameters and other data related to the simulation. Depending on usage, there can be one or more of the above components. The figure below shows the connections between the components. Processing Host Client