View Issue Details

IDProjectCategoryView StatusLast Update
0005547GNUnettransport servicepublic2019-05-03 18:55
ReporterChristian GrothoffAssigned To 
Status confirmedResolutionopen 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.12.0Fixed in Version 
Summary0005547: communicator basic test plan
DescriptionThis issue describes the most basic test we should do for communicators.

The high-level test setup should be a test driver which also pretends to be *two* transport services, using different service configurations (say udp1.conf and udp2.conf) with the main difference being different ports/UNIXPATHs and the PeerIdentity. There, it needs to offer support for (some of) the messages that the gnunet_transport_communication_service.h API transmits to the transport service. The test driver should furthermore launch two communicator processes, again based on different configurations (udp1.conf and udp2.conf) differing in the port that is being used.

The test should then expect both communicators to notify it about their own address (i.e. In response, the transport should give to one of them the address (and PID) of the other (triggering CommunicatorMqInit). Depending on the plugin, it should then expect an MQ to be created at one end (UDP) or both ends (TCP). It should then use the MQ to transmit a message, and verify that the other peer receives the message. The basic test should only test uni-directional communication, but with different message sizes (0-UINT16_MAX bytes).

The test should transmit short messages (0000118:0000128 bytes) for 2s and long messages (32kb) for 2s, followed by one round of messages ranging from 0 to 65535 in steps of 5 bytes (correctness only). The test should then output the achieved goodput for short messages (# 128b * msg received / 2s), good put for long messages (# 32kb * msg received / 2s), and also the latency (average, for both categories).

This test should be universally applicable for all communication protocols given the right pair of configuration files. Thus, the suffix of the test binary (i.e. test_communicator_basic_$SUFFIX) should be used to determine the configuration files (i.e. test_communicator_basic_$SUFFIX{1,2}.conf), so that the same test C code can be re-used for testing TCP, UDP, HTTP (with client & server) or any other communication protocol.
TagsNo tags attached.


child of 0005710 assignedChristian Grothoff TNG meta issue 


There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2019-02-08 18:54 Christian Grothoff New Issue
2019-02-08 18:54 Christian Grothoff Status new => assigned
2019-02-08 18:54 Christian Grothoff Assigned To => ch3
2019-02-12 09:22 Christian Grothoff Target Version => 0.12.0
2019-05-02 14:40 Christian Grothoff Relationship added child of 0005710
2019-05-03 18:55 Christian Grothoff Assigned To ch3 =>
2019-05-03 18:55 Christian Grothoff Status assigned => confirmed