Attention is currently required from: laforge, pespin.

fixeria has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36150?usp=email )

Change subject: stp: add testcases for M3UA-over-TCP ......................................................................

Patch Set 4:

(1 comment)

File stp/STP_Tests_M3UA.ttcn:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36150/comment/c0b97bda_6934b... PS4, Line 1229: f_sleep(1.0);

can you explain this?

In the case when `ASP[idx_b]` is configured as the client (i.e. osmo-stp connects to the testsuite; `idx_b >= NR_M3UA`), in `f_M3UA_CLNT_asp_up_act()` we're expecting to receive `ASPACT` and then sending `ASPACT_ACK` to it. Right after that, we're sending some random data via `ASP[idx_a]`, which we then expect to receive via `ASP[idx_b]` (see `f_test_traffic()`).

There is a chance that the random data sent via `ASP[idx_a]` would reach osmo-stp earlier than the `ASPUP_ACK` we sent for `ASP[idx_b]` -- this is what I was seeing when running `TC_m3ua_tcp_cli_srv`. In this test scenario only `ASP[idx_b]` is using TCP, and there is some delay likely caused by Nagle's algorithm.

It's not my invention (you can find `f_sleep(1.0)` in the code above), but it does help to avoid the race condition.