search

private-octopus / picoquic

Minimal implementation of the QUIC protocol
MIT License
561 stars 165 forks source link

stream offset have 'hole' while sub-path send failed (what do I have to do while sub-path socket-errors) #1409

Closed dongsf closed 2 years ago

dongsf commented 2 years ago

I have a multi-path use case. What do I have to do while sending data with socket errors? My process is same as the function picoquic_packet_loop() code: if (picoquic_socket_error_implies_unreachable(sock_err)) {

                    log_e("socket error %d !" , errno);

                    picoquic_notify_destination_unreachable(last_cnx, current_time,
                        (struct sockaddr*)&peer_addr, (struct sockaddr*)&local_addr, if_index,
                        sock_err);
                }

I turn off the net interface of one sub-path, there is a offset 'hole' in the stream sometimes, and stream callback_fn is not triggered anymore in the server side. what should I do? f639a6ff839ab4a2.zip The qlog show there is a 'hole' between "packet_number": 64 and "packet_number": 53

huitema commented 2 years ago

Seems like a bug... The packets queued on the failing path should be declared lost, and their content resent on other paths. I will check the traces to understand why this did not happen.

huitema commented 2 years ago

To understand the bug, we need to write a new test -- a variation of the current multipath tests in which one of the path is declared failing midway through the connection. I am traveling and cannot do that immediately, but help is welcome!

huitema commented 2 years ago

@dongsf I am writing tests now. The good news is that I appear to have a repro -- but only when using the "simple multipath" option. Is that also what you are using?

huitema commented 2 years ago

@dongsf -- I think that the PR #1410 solves this issue. Can you verify?

dongsf commented 2 years ago

Yes ,I am using the "simple multipath" option. https://github.com/private-octopus/picoquic/pull/1410 solves this issue. Thanks!