View Issue Details

IDProjectCategoryView StatusLast Update
0005547GNUnettransport servicepublic2019-11-16 18:41
ReporterChristian GrothoffAssigned Toschanzen 
PrioritynormalSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionSVN HEAD 
Target Version0.13.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. 127.0.0.1:PORT). 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.

Relationships

parent of 0005797 assignedch3 Race condition in TNG unix communicator test 
parent of 0005796 assignedch3 Wrong return value of TNG communicator test 
child of 0005710 confirmed TNG meta issue 
Not all the children of this issue are yet resolved or closed.

Activities

ch3

2019-07-07 22:48

developer   ~0014661

This was started with test_communicator_unix.
transport-testing2.{h|c} provides a (communicator-independet) api for testing communicators. (Which is not finished, yet.)
The unix test should be able to be used as a generic template for testing other communicators.

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
2019-07-07 22:48 ch3 Note Added: 0014661
2019-07-08 11:20 ch3 Relationship added parent of 0005797
2019-07-08 11:21 ch3 Relationship added parent of 0005796
2019-10-09 21:28 schanzen Assigned To => schanzen
2019-10-09 21:28 schanzen Status confirmed => assigned
2019-11-16 18:41 Christian Grothoff Target Version 0.12.0 => 0.13.0