View Issue Details

IDProjectCategoryView StatusLast Update
0005547GNUnettransport servicepublic2020-06-01 22:00
ReporterChristian Grothoff Assigned Toschanzen  
PrioritynormalSeverityfeatureReproducibilityN/A
Status closedResolutionfixed 
Platformi7OSDebian GNU/LinuxOS Versionsqueeze
Product VersionGit master 
Target Version0.12.2Fixed in Version0.12.2 
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 (~128 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 closedschanzen Race condition in TNG unix communicator test 
parent of 0005796 closedschanzen Wrong return value of TNG communicator test 
child of 0005710 confirmed TNG meta issue 

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.

schanzen

2019-12-22 14:58

administrator   ~0015208

61a8f2c46..5402016fc now is a more or less rewritten and extended version. It supports:

- Building any communicator test from the same C source
- Goodput short messages (128bytes / 2 s)
- Goodput long messages (32kb / 2 s)
- Test from 5 to 64k byte sizes of messages

Missing:
- Average latency
- Tests other than unix (tcp,udp)
- Unclear if test logic triggers strange fc/cc side effects at some point

schanzen

2019-12-27 11:37

administrator   ~0015224

Closing this bug as test now exists with requested properties.
Bugs in TNG/Communnicators exists but will be tracked in other tickets.

schanzen

2020-01-13 17:40

administrator   ~0015267

0.12.2 released

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
2019-12-22 14:58 schanzen Note Added: 0015208
2019-12-27 11:37 schanzen Status assigned => resolved
2019-12-27 11:37 schanzen Resolution open => fixed
2019-12-27 11:37 schanzen Fixed in Version => 0.12.2
2019-12-27 11:37 schanzen Note Added: 0015224
2020-01-01 04:15 schanzen Target Version 0.13.0 => 0.12.2
2020-01-13 17:40 schanzen Note Added: 0015267
2020-01-13 17:40 schanzen Status resolved => closed