[tech] server testing

Hi,
I am in the process of writing server framework for Gemini (you can expect 
announcement soon) and I am looking for more ways how to test it.

I did use https://github.com/michael-lazar/gemini-diagnostics and right 
now I am looking for ways how to test behavior on slow or weird 
connections. I am not too familiar with low level networking so I am 
looking for more information here. Specifically I would like to test 
scenario where client request comes in multiple packets over very slow 
connection. Is there some automated test which can do that for me? Or how 
could I test it manually (on Linux)?

Thank you everyone for your work on Gemini!
--
Sgiath
GPG: 0x70F9C7DE34CB3BC8

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

On Tue, Apr 20, 2021 at 10:18:03AM +0000,
 Sgaith <Sgiath@pm.me> wrote 
 a message of 46 lines which said:

> I am not too familiar with low level networking so I am looking for
> more information here. Specifically I would like to test scenario
> where client request comes in multiple packets over very slow
> connection. Is there some automated test which can do that for me?
> Or how could I test it manually (on Linux)?

On Linux, you can use the "tc" program to tell the kernel to drop
and/or delay packets. For instance (DON'T TYPE IT BEFORE READING IT!)

tc qdisc add dev  tap0 root netem delay 150ms loss 50%

Will add 150 ms of delay to all packets going through the network
interface tap0 and in addition will drop (more or less) half of them.

% ping -c 10 gemini.circumlunar.space 
PING gemini.circumlunar.space(2604:180:f3::185 (2604:180:f3::185)) 56 data bytes
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=1 ttl=54 time=78.6 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=2 ttl=54 time=78.7 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=3 ttl=54 time=78.4 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=4 ttl=54 time=78.6 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=5 ttl=54 time=78.6 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=6 ttl=54 time=78.5 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=7 ttl=54 time=79.7 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=8 ttl=54 time=78.6 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=9 ttl=54 time=78.4 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=10 ttl=54 time=82.8 ms

--- gemini.circumlunar.space ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 23ms
rtt min/avg/max/mdev = 78.380/79.089/82.831/1.323 ms

% sudo tc qdisc add dev eth1 root netem delay 150ms loss 50% 

% ping -c 10 gemini.circumlunar.space                       
PING gemini.circumlunar.space(2604:180:f3::185 (2604:180:f3::185)) 56 data bytes
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=1 ttl=54 time=229 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=2 ttl=54 time=230 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=3 ttl=54 time=229 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=4 ttl=54 time=233 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=7 ttl=54 time=229 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=8 ttl=54 time=230 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=9 ttl=54 time=229 ms
64 bytes from 2604:180:f3::185 (2604:180:f3::185): icmp_seq=10 ttl=54 time=229 ms

--- gemini.circumlunar.space ping statistics ---
10 packets transmitted, 8 received, 20% packet loss, time 71ms
rtt min/avg/max/mdev = 228.666/229.638/232.723/1.252 ms

Thanks, that definitely helped!

I also figured out that I could edit the `gemini-diagnostics` to send 
really large request to force it to be split into multiple packets to test 
this kind behavior.

Have a nice day
--
Sgiath
GPG: 0x70F9C7DE34CB3BC8

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments