Closed jkarneges closed 7 years ago
Please use the new \{message.marker}
functionality together with --message-marker
option.
At the source you have to generate the messages containing the string of the format TCPKaliMsgTS-%016llx.
with the timestamp in μs).
At the destination you can use tcpkali to process these messages.
Here how it might look if your source is tcpkali in the listen mode and the target is tcpkali in the client mode:
tcpkali --ws -l8080 --listen-mode=active -r10 -m '\{message.marker}' -d
tcpkali --ws 127.1:8080 --message-marker -d
Here how it looks like, roughly:
Of course, instead of tcpkali you can trivially generate and inject the message marker tag yourself using most languages and frameworks.
Awesome! Initially I didn't think to use timestamps since I always worry about clock drift, but as long as the timestamps are generated by another program living on the same machine then it should work fine. Much easier to use than my suggestion.
It would be great if tcpkali could externally invoke a message delivery system and then confirm receipt on the client connections. One idea I have is to be able to pass a program name via argument, which tcpkali could run on startup and then feed it unique strings via stdout.
Tcpkali could then generate a unique strings to be used as a latency markers, send the strings to the child process, and wait to see when the strings shows up on the client connections.