Closed kenmcmil closed 5 years ago
Thanks! That is very likely, since quant itself won't generate STOP_SENDING
, and I have not found a public server that will either. Do you have a way for me to reproduce this locally?
By the way, the same thing happens with MAX_STREAM_DATA.
Some options for a local repro:
1) Linux binary 2) Docker container.
The latter option is nice because we can use the public repository, but it requires some software setup.
I have docker running, do you have some simple instructions for how to run your test with it locally?
Sorry I was out for a while. Here are some directions for running the test under docker...
... run a quant server under debugger on port 4443 ...
$ docker run -i -t --network host kenmcmil/quictest:v0.7
/app# cd test
/app/test# python test.py iters=1 server=quant test=quic_server_test_max run=false
If you see something like this, it means the server sent CONNECTION_CLOSE, probably because of this issue:
quic_server_test.ivy: line 511: error: assumption failed
client return code: 1
FAIL
error: 1 tests(s) failed
Unfortunately this doesn't work for me under Windows -- only under Linux. On Windows the packets don't escape the docker container. I can't tell if this is a docker issue, a windows firewall issue, or something else.
This should be fixed in fb439362a and later
It looks like quant is not opening bidirectional streams on receipt of STOP_SENDING, per the change in draft-17. Here is the relevant language:
I haven't checked whether it opens streams on MAX_STREAM_DATA.
Here' s log showing the receipt of STOP_SENDING on stream 4 at 18.579: