CLASIFICACIÓN VEHICULAR PARA AFOROS

8. MARCO TEÓRICO

8.1 CLASIFICACIÓN VEHICULAR PARA AFOROS

8.6.5 Windows Management Instrumentation

To automate windows configuration tasks, Microsoft provides Windows Management Instrumentation (WMI). This standard has been introduced in Section 6.2.4. For Verinec, WMI is used, although there is no pure Java implementation of WMI the authors know of. Distribution to Windows devices can only be performed if Verinec runs itself on a Windows machine. DistWMI uses the Jawin library [Halloway and Gehtland, 2005] to execute WMI commands. Jawin is a general integration layer for accessing Windows libraries through the Component Object Model (COM). It allows to use any scriptable component of Windows without the need to write a wrapper using the Java Native Interface (JNI). It comprises the Jawin Type Browser to generate stub classes for a library. This has been used by [Zurkinden, 2005] to generate all necessary classes to write WMI scripts in Java. The distributor simply retrieves the classes indicated in the wmi XML elements and calls the specified methods on them.

As its name suggests, Jawin can only be used on Windows. This means that the Verinec application needs to run under Windows, at least in a virtual machine, in order to use the WMI distribution method. According to [Zurkinden, 2005], there exists no multi-platform WMI client. There are WBEM frameworks implemented in pure Java, but they use HTTP as transportation protocol. For reasons mentioned in Section 6.2.4, WMI uses DCOM and provides no HTTP adapter. The only other alternatives would have been to implement some sort of Verinec agent to install on the Windows machines to configure. It could have been implemented in Java, using a library to access the registry18of that machine, or in .NET, using WMI only on the target machine. However, agents to install on target devices are against the design principles of Verinec, thus the Jawin solution was chosen.

The DistWMI distributor can distribute result-wmi files. Inside, result-wmi contains WMI function calls expressed in XML. This Schema part was originally developed by [Zurkinden, 2005] and has been integrated into the translation Schema. One or several wmi elements specify on which classes to operate and the WQL queries to select the desired instance. Child elements are used to specify the methods to call and their parameters.

The tr:wmi target (not to be confused with the resulting configuration wmi element) allows to specify how to connect to the machine to configure. The host attribute specifies the machine to connect to. username allows to override the user name to use when connecting to a remote system. Otherwise the name of the currently logged in user is taken.19 _{The Windows domain can}

be indicated using the syntax user@domain. If there is a password required for the user to connect, it can be specified in the password attribute.

8.7 Verification Module

Verification requires information in addition to the network definition. To tell whether a configuration is semantically correct or not, Verinec needs a definition of what the semantics are. Test cases are used to specify requirements. This section presents the network simulator used to execute the tests and explains the implementation of network test cases. The section is concluded by revisiting the role model and explaining how the tests are used to define the roles. An elaborate discussion on verification implementation is found in [Jungo, 2008], who also wrote almost all code to implement the module.

8.7.1 The Verinec Network Simulator

The most important piece to test the network configuration is a simulator. A custom discrete time simulator has been built for Verinec [Jungo et al., 2004]. Based on events, it models the Internet layer model [Tanenbaum, 2003]. Every operation from transport to application layer is simulated and logged into an event tree. The simulation is started with a list of input events in XML format. Processing of those events can generate follow-up events which are scheduled at a later time. The XML event log is more accurate than is possible to get from a real network, as the

18_{For example the free implementations jRegistry Key www.bayequities.com/tech/Products/jreg key.shtml or}

JNIRegistry www.trustice.com/java/jnireg/.

19_{For unknown reasons, the WMI framework does not support connecting to the localhost as a different than the}

104 CHAPTER 8. VERINEC IMPLEMENTATION

causal chain is maintained. In log file analysis, it is difficult to decide for sure if an entry is caused by a certain event, particularly when events occur on different devices. In the Verinec simulation, this relationship is known and preserved in the event log by the element hierarchy. Events are added as child of the event that caused them. The output of the simulation can also be visualised in the GUI to get an idea of what is going on in the network.

An example simulation input is shown in Listing 29. At time 1, a UDP packet has to be sent on client. The dst attribute tells to ping to contact the node server2. On the destination machine, a “ping server” must be started explicitely. It responds to receiving an UDP packet by sending a UDP packet back to the sender. This allows to see whether communication is possible in both directions, which is usually desired. Although the program is called “ping” in Listing 29, it is actually an attempt to send a UDP packet to the host. Contrary to ICMP “echo request” messages, which are treated by the TCP/IP stack, UDP packets are only handled if there is some service running on the target. Note that the best solution would be to not start this service with an simulation input event, but automatically when a generic-service is present in the node definition. This should be implemented in a future version of Verinec.

Listing 29: Simulation Input <events xmlns="http://diuf.unifr.ch/.../events">

</event>

</events>

Listing 30 shows a fragment of the resulting output event tree. The sequence shows the client node sending an arp broadcast to determine the MAC address for the IP address of the server. After the arp reply has been received, the actual UDP packet will be sent to the server IP. The simulation log contains events from all layers. Even for the simple ping example, about 50 events where logged. Each transmission over the network is received by all nodes connected to the same hub. The simulation output is not very readable in its XML form. Verinec can however visualise the events in the GUI, helping to see what happens. Tests can be applied to the event tree to see whether the expected events occur, as discussed later in this section.

The simulator is built on the simulation framework DesomJ [Page et al., 2000]. This pure Java framework allows to combine the event-based with the process-oriented simulation approach. In Verinec, stateless protocols are implemented as event-driven modules, while stateful protocols are process-oriented. On top of the IP stack with TCP and UDP, the simulator implements DNS and generic TCP and UDP services to test handshakes. Below IP, ARP, Ethernet and “physical” data transfer are implemented. [Hug, 2006] implemented a complete packet filter for the simulator. As the other services, it directly uses the Verinec XML language as configuration. The simulator can be used to implement the use case from Section 4.1.

8.7. VERIFICATION MODULE 105

Listing 30: Simulation Output

</event>

<event time="7" node="client" layer="2" service="ethernet" src="00:0b:cd:47:a1:e4" dst="ff:ff:ff:ff:ff:ff"

packetid="5e23bf9a:1143a41fe78:-7fcb" interface="eth1"> <ethernet type="framesend" payloadtype="ADDRESS_RESOLUTION" /> <reason xpath="/vn:nodes/vn:node[3]/...ethernet/@hwaddress" />

<event time="9" node="server2" layer="2" service="ethernet" src="00:0b:cd:47:a1:e4" dst="ff:ff:ff:ff:ff:ff"

packetid="5e23bf9a:1143a41fe78:-7fcb" interface="eth0"> <reason xpath="/vn:nodes/vn:node[10]/...ethernet/@hwaddress" /> <ethernet type="framereceived" payloadtype="ADDRESS_RESOLUTION"/> <event time="9" node="server2" layer="3" service="arp"

src="00:0c:29:74:dc:03" dst="00:0b:cd:47:a1:e4">

Integrate the Simulator with Network Applications

To avoid having to write all servers and clients anew, the java.net infrastructure is used. Java creates sockets according to the Strategy design pattern [Gamma et al., 1995], enabling a flexi- ble way to provide own implementations of sockets. The java.net.Socket and ServerSocket classes are wrappers around an instance of type java.net.SocketImpl. Using the static method setSocketImplFactory() on Socket and ServerSocket, it is possible to change the default implementation of the engine. [Jungo, 2008] implemented a factory to create sockets which do not send packets to the actual network, but into the simulation framework.

DNS queries are a special case. The resolution of domain names into IP addresses happens in the java.net.InetAddress class. It does not use the Socket class. In the standard Java framework, it is not possible to change the way name resolution is performed. However, since version 1.4, the Sun Java virtual machine allows to specify alternative name service implementations. The method is specific to the Sun implementation and is not guaranteed to stay in later versions.20 _{The DNS}

configuration feature is not well documented in the official Java documentation21_{, but a rather}

complete overview is provided by [Kuzmik, 2006]. First, the sun Java machine has to be informed about the class name(s) of available name service descriptors. This is accomplished by placing a configuration file with the name sun.net.spi.nameservice.NameServiceDescriptor into the folder META-INF/services/ in the classpath. It simply lists the fully qualified class names of all implementations.

The specified classes have to implement the interface NameServiceDescriptor. They are facto- ries to create NameService instances. Listing 31 presents a minimal factory. It is selected by setting the system property sun.net.spi.nameservice.provider.X to a value "<type>,<name>", for example "dns,mine". X is a number starting from 1, allowing to specify more than one provider. Sun’s JVM cycles through the classes listed in the configuration file and uses the two get-methods to determine whether type and name match this property.

20_{Up to the current Java 1.6, it is still valid.}

106 CHAPTER 8. VERINEC IMPLEMENTATION

Listing 31: MyNSDescriptor.java package fully.qualified;

public class MyNSDescriptor implements NameServiceDescriptor { public NameService createNameService() throws Exception {

return new MyNameService(); }

public String getProviderName() { return "mine";

}

public String getType() { return "dns";

} }

MyNameService implements the interface NameService, which requires two methods to translate a name into a list of associated IPs or reverse translating an IP into a host name. The Verinec NameService implementation finally resolves names through DNS packets sent over the simulated network. On the other end of the simulated request, a node running a Java DNS server answers according to the XML network definition for that server.

Limitations of the Simulator

The Verinec simulator does not model network capacity and latencies. It would be interesting to consider the physical behaviour of network connections. This would permit to do performance analysis or test load balancing mechanisms. As discussed in Section 2.3.1, the bare existence of a connection does not guarantee reliable communication. If the network is congested with too much traffic, it is unusable even if connectivity would be possible.

Modelling latency would allow to create a new kind of tests that control whether requirements on the connection quality can be guaranteed. However, to model signal retardation and capacity, a database for the behaviour of typical network components is required. Even then it remains uncertain whether the predictions are correct, as latency depends on subtle factors. This area is probably better covered by tests on the real network.

Another feature not found in the Verinec simulator is simulating transmission errors. The impact of loosing some packets is mostly irrelevant for Verinec. This feature, found in classical network simulators like [ns, 2005], is useful to test the correctness of protocols. In Verinec, the protocols are assumed to be correctly implemented. But at some point, high collision rates affect the capacity and latency perceived at the end points because of the required retransmissions. If the simulator is extended to model capacity, collisions should also be taken into account. This could be achieved by modelling the capacity with Markov chains. This approach is taken in ns2 to avoid the almost impossible “exact” simulation of collisions and service degradation.

A master thesis by Philippe Der Hovsepian is currently exploring another approach to capacity testing. With the Verinec configuration being expressed in XML, it is not too difficult to translate it into input for the ns2 application. The simulation result from ns2 is then examined and the results presented in Verinec.

8.7.2 Constraint Language in XML

XML Schemas are well suited to specify the syntax of XML documents. However, there is no possibility to base constraints on actual element or attribute values. For example, it is not possible to formulate a constraint that either attribute A or child element B must be present, but not both. There exist several other XML description languages to do this.

Most famous among them is probably Schematron22. It was standardised by the ISO in the Document Schema Definition Languages framework [JTC1/SC34, 2006]. Schematron makes ex- tensive use of XPath23 _{. One XPath expression is used to find a node in the document. A list}

22_{www.schematron.com/}

In document SISTEMA INFORMÁTICO DE AFOROS VIALES (SIAF) (página 41-46)