Table Of Contents
Table Of Contents

Easy to Handle Changes

Some changes in the model don’t change fingerprints at all, and are unlikely to cause regressions. These changes include renaming C++ classes, functions and variables, and extracting methods or classes, refactoring algorithms.

For example, we extract some part of the handleUpperCommand() function in the Udp module to a new function:

--- /docs/doc/src/tutorials/fingerprint/
+++ /docs/doc/src/tutorials/fingerprint/
@@ -143,6 +143,12 @@
         throw cRuntimeError("Unknown protocol: %s(%d)", protocol->getName(), protocol->getId());
+void Udp::udpConnect(cMessage *msg) {
+    int socketId = check_and_cast<Request*>(msg)->getTag<SocketReq>()->getSocketId();
+    UdpConnectCommand *ctrl = check_and_cast<UdpConnectCommand*>(msg->getControlInfo());
+    connect(socketId, msg->getArrivalGate()->getIndex(), ctrl->getRemoteAddr(), ctrl->getRemotePort());
 void Udp::handleUpperCommand(cMessage *msg)
     switch (msg->getKind()) {
@@ -154,9 +160,7 @@
         case UDP_C_CONNECT: {
-            int socketId = check_and_cast<Request *>(msg)->getTag<SocketReq>()->getSocketId();
-            UdpConnectCommand *ctrl = check_and_cast<UdpConnectCommand *>(msg->getControlInfo());
-            connect(socketId, msg->getArrivalGate()->getIndex(), ctrl->getRemoteAddr(), ctrl->getRemotePort());
+        udpConnect(msg);

The refactoring doesn’t change the fingerprint because the code is functionally the same; it doesn’t create any new events or data packets, and it doesn’t change timing, or anything that the fingerprint calculation takes into account:

$ inet_fingerprinttest -m EasyToHandleChanges
. -f omnetpp.ini -c Ethernet -r 0  ... : PASS
. -f omnetpp.ini -c Wifi -r 0  ... : PASS

Ran 2 tests in 6.714s


Log has been saved to test.out
Test results equals to expected results