How to restore a suspended path/connection?

[a-andre]

Hi,
I have a single path connection, where ping packets are sent from client to server in datagram mode.
The idle timeout is set to 0.

When the wired connection between client and server is cut, the callback event picoquic_callback_datagram_lost is triggered on client-side and after about 2 seconds there is picoquic_callback_path_suspended.
Now, when I restore the wired connection, I would expect to see picoquic_callback_path_available (after some time), but nothing happens.
Wireshark also doesn't show any packet being sent to the server.

How can a suspended path be re-activated?

Note, the path is restored and ping continues if the wired connection is fixed within these about 2 seconds.

[huitema]

Can you collect a qlog so we can see what is happening?

Also, are you sending new pings after the path comes back?

[a-andre]

Here are the qlog files
cd25160f92e2bf05.server.log
cd25160f92e2bf05.client.log

Pings are sent continuously, i.e. data is added to a buffer queue, picoquic_wake_up_network_thread() is called, which triggers picoquic_packet_loop_wake_up, which calls picoquic_mark_datagram_ready().

After the disconnection, nothing happens after picoquic_mark_datagram_ready(), i.e. picoquic_callback_prepare_datagram is not triggered.

[a-andre]

Does it help?

[a-andre]

The solution seems to be to call picoquic_enable_keep_alive().

Maybe the function could be mentioned in the documentation.

[huitema]

I think we have a bit of confusion because you are using mutipath API such as "path available", but your connection does not negotiate the use of the multipath extension. That may be a weakness in the code, maybe we should better support that API even if you are not using multipath.

After you unplug the path, the next attempt to send data causes a "socket error". We see that in the log:

[11560352, "info", "message", { "message": "Could not send message to AF_to=2, AF_from=2, if=6, ret=-1, err=101"}],

Then, the connection stops after a few attempts to contact the server.

We do have a test for that scenario, with the path disconnected for 2 seconds and then reconnected, the "blackhole" test, but it does not simulate the socket error. It also assumes that the application is sending data packets, which have to be repeated, when in your case the application just sends datagrams. Maybe we should try to add new tests for these variants.

Did you repeat your experiment of unplugging the cable and then plugging it back while using picoquic_enable_keep_alive()? The function causes a ping to be sent at regular intervals, to avoid the server or the NAT bindings to time out. I would like to understand why it solves your problem.

[a-andre]

I did a different test, which I assumed would be similar to the "unplugging" experiment.

Now I did the "unplugging" again and the problem is not solved by `picoquic_enable_keep_alive(). Even worse, there is no reconnection if the cable is plugged in again within the about 2s.

The final goal is to restore paths in a multipath scenario. And for that to work, I think, restoring a single path/connection should also work, because in multipath all paths could be unavailable at the same time.

Is there a way to signal that "socket error" to the application?