You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Excellent work. I have been looking for the file transfer application from home to the office without the expensive relay server. Although there are techniques like UDT, QUIC, STUN or something else, the qft seems as the only takeaway and nearly workable one. I have recompiled the binaries for linux and raspberry-pi here . The linux version is compiled in static way and is hoped to solved the missing glibc6 problem.
There are still two problems I met:
The first is that the qft is workable when at least one of the sender or receiver have global Internet IP. If both the machines are behind the NAT router, the process would stop after sending the first package like this:
# the receiver
./qft receiver tudbut.de:4277 KEYS hi.txt.gz
Holepunching IP:PORT (partner) and :38116 (you).
Connecting...
Holepunch and connection successful. # [Freeze here, do not receive anything]# the sender
./qft sender tudbut.de:4277 KEYS hi.txt.gz
Holepunching IP:PORT (partner) and :53757 (you).
Connecting...
Holepunch and connection successful.
Length: 20003073
Sent 983040 bytes; Speed: 512 kb/s
10s passed since last packet ==> Contact broke. Trying to resend packet...
10s passed since last packet ==> Contact broke. Trying to resend packet... # [Repeat this line]
In my opinions, the UPnP setting or something else is needed for any one of the mchine, but I'm not sure what exactly is.
The other one is that when the packages size is larger than 256, it's more likely that the process will fail or packages will be dropped. I think this should be solved with paralelling transfering of ~1MB blocks with small package size.
The text was updated successfully, but these errors were encountered:
I think one of your NATs has full port randomization, meaning the port changes when the destination changes, not just when the sender changes. That is really difficult to work around, sadly. Packets are already sent in bursts and later start synchronizing themselves to find the perfect balance, the packet size shouldn't matter too much, and packet drops are entirely fine, because qft corrects them.
Excellent work. I have been looking for the file transfer application from home to the office without the expensive relay server. Although there are techniques like UDT, QUIC, STUN or something else, the qft seems as the only takeaway and nearly workable one. I have recompiled the binaries for linux and raspberry-pi here . The linux version is compiled in static way and is hoped to solved the missing
glibc6
problem.There are still two problems I met:
The first is that the qft is workable when at least one of the sender or receiver have global Internet IP. If both the machines are behind the NAT router, the process would stop after sending the first package like this:
In my opinions, the UPnP setting or something else is needed for any one of the mchine, but I'm not sure what exactly is.
The other one is that when the packages size is larger than 256, it's more likely that the process will fail or packages will be dropped. I think this should be solved with paralelling transfering of ~1MB blocks with small package size.
The text was updated successfully, but these errors were encountered: