Resume after lost connection

[stefnotch]

When using this app, I frequently encounter

Disconnected from hotspot 
Transfer error: Peer connection closed

on my smartphone. This may be my own fault for using GrapheneOS.

However, once an error has happened, I do not see a way of resuming the file transfer. I have to set up the entire transfer again from scratch.

System info
Sending: Windows 11
Receiving: Android, Google Pixel 8, with GrapheneOS
App version 9, used the no Bluetooth mode

[spieglt]

Sorry to hear about the frequent disconnections. I'm not sure offhand why the hotspot would disconnect, could have to do with GrapheneOS or could be the Windows side stopping the hotspot for some reason.

When sending multiple files, it should check for a file by the same name, location, and contents in the destination, and skip sending them if already present. Are you finding this to be the case? That's the closest I've gotten to transfer resumption because I haven't wanted to mess with tracking session state on both sides, but I probably do need to improve the protocol someday which could make this possible.

[stefnotch]

I'd be happy to try and look into why it disconnects so frequently. Any pointers on what I should look at or try out?

Yes, it does do the check. My problem was that I was transferring >100 small files. With the current protocol, it would check for each file, then decide that it is done, and proceed to the next one.
Except that that takes quite a while. Worse yet, with the spotty connection, I would sometimes transfer zero new files before it went "Disconnected from hotspot".
I ended up working around it by manually sending smaller groups of files.

(Though on one occasion I may have gotten a corrupted/half-finished file due to a disconnect)

[spieglt]

I'm not sure, I haven't had this experience on any of my devices so I'm afraid I don't know how to be much help troubleshooting this. I wonder, does it disconnect frequently if you put all the files in a zip or other archive and send just one larger file?

[stefnotch]

I tried it again today. I first tried the Bluetooth mode, but after I accidentally pressed "cancel" when pairing it for the first time, it just refused to show me the pairing screen ever again. After that, I tried turning Bluetooth off and back on. Which also failed, since Windows wouldn't let me turn Bluetooth back on. Go figure.

So I tried the wifi mode again, this time with a large file.
This too ended up in a broken connection. It stopped the moment my phone screen turned dark.

This was with both my phone and my laptop connected to a public wifi.

Start the transfer on the other device and scan the QR code when prompted.
Firewall rule already in place.
Waiting for connection...
Hosted network flyingCarpet_a78c has started
Connection accepted
=========================
Sending file 1 of 3. Filename: 2025-05-20_13-18-03_part2.mp4
File size: 260.60MB
Error sending file: std::io::Error: An existing connection was forcibly closed by the remote host. (os error 10054)
Hosted network stopped

I then tried babysitting it and always tapping on the screen. This did work for a bit longer. I actually managed to transfer one file.

Start the transfer on the other device and scan the QR code when prompted.
Firewall rule already in place.
Waiting for connection...
Hosted network flyingCarpet_bcac has started
Connection accepted
=========================
Sending file 1 of 3. Filename: 2025-05-20_13-18-03_part2.mp4
File size: 260.60MB
Sending took 1 minutes 17.67 seconds
Speed: 26.84mbps
=========================
Sending file 2 of 3. Filename: 2025-05-20_13-18-03_part1.mp4
File size: 264.80MB
Error sending file: std::io::Error: An existing connection was forcibly closed by the remote host. (os error 10054)
Hosted network stopped

[spieglt]

Was it on Android or Windows that you hit Cancel and then the UI was broken? Sounds like your Windows Bluetooth problem may be outside of the scope of Flying Carpet? Another helpful thing to try can be to make sure that both devices are unpaired from each other.

Phones can definitely stop the WiFi connection if the app goes out of focus or the phone goes to sleep. This is outside of my control, but is something I should call out in the readme and instructions, so thank you for the reminder.

[stefnotch]

It was on Android where I hit cancel. I'm not entirely sure what one would do about the Windows Bluetooth issues. I figured it's at least interesting to mention it.

Is there a way of convincing FlyingCarpet to just an existing WiFi connection? When I connect my phone to a manually created WiFi hotspot, I get a very stable connection.
Or alternatively, is there a way of getting a more permanent wifi connection with an API like this one? That's what those "connect to wifi by scanning a QR code" apps use.

[spieglt]

I've thought about having it use an existing connection, as a way to get Apple-to-Apple transfers working. But last time I thought about it, I saw that there's no way to get the hotspot's user-chosen SSID, so there's no way to pass it to the peer over Bluetooth/QR code.

Using existing connections would be useful in other situations like yours, but it would be a big project. If two devices are on the same network, they don't need a hotspot, so devices would first have to find out if they have active WiFi connections, and if so, scan their current networks for a device running Flying Carpet. This would require adding some kind of authentication because right now, the Bluetooth PIN or physical QR code scan is used to ensure you're communicating with the device you intend to.

The detection could I guess be done by UDP multicast, but I'd have to figure that out on every platform. Or by trying the port used by Flying Carpet on every IP address on the device's subnet, but that could be tricky on large subnets and makes it hard to select between multiple devices serving traffic on the port. That wouldn't matter if one device joins another's hotspot (in which case you could just try the port on the gateway¹ and one of them will be right), but could matter on large LANs. Anyway, I agree it would be useful and I'd like to take it up at some point. LocalSend probably fits this use case well?

As for the API you sent, I'd wonder about The platform ultimately chooses which access point to accept based on the input from your app and others. Flying Carpet prevents internet access during the transfer on a lot of platforms so the OS wants to switch away from it.

Footnotes

1. Come to think of it, I don't know if you can get the current gateway on iOS without the network changing. ↩