5 ms·
On a related note, I recently learnt that if you're on the same local network, there's a much faster way to transfer than the old tar|nc trick[0]: udpcast. You
by unhammer 8y ago
On a related note, I recently learnt that if you're on the same local network, there's a much faster way to transfer than the old tar|nc trick[0]: udpcast. You do
$ udp-sender --min-receivers 1 --full-duplex --pipe 'tar czvf - theDirectory'
on the sender and
$ udp-receiver --pipe 'tar xzp'
and at least on my home network it's 11x faster than tar|nc. There are some caveats[1] about udp not working well everywhere, and you may have to open ports 9000 and 9001 and of course it's not encrypted at all, but for copying large ISO's and such when you can't find your usb stick it's great. Just remember to compare checksums afterwards.
[0] http://www.spikelab.org/blog/transfer-largedata-scp-tarssh-tarnc-compared.html http://www.spikelab.org/blog/transfer-largedata-scp-tarssh-t...
[1] https://superuser.com/questions/692294/why-is-udcast-is-many-times-faster-than-netcat https://superuser.com/questions/692294/why-is-udcast-is-many...
- userbinator 8y agoJust remember to compare checksums afterwards. Preferably a cryptographic hash... UDP is known for not being reliable at all, and that's partly why it's so fast --- the sender doesn't care whether the packets reached the receiver, it just sends as fast as it can.
- Filligree 8y agoCRC is fine in this case. Oh, they should use SHA anyway because why not, but CRC is only vulnerable to deliberate manipulation or exceedingly abstruse bit-flips. When the failure mode is lost packets, it's perfectly fine.
- mbrumlow 8y agoWell sort of. The sender will in a lot (most) of cases care, its the protocol (UDP) that has no automatic checking, or reporting. This sort of stuff is left up to the programmer. The power of UDP allows the sender to have more control on things like how often transmissions are are acknowledged (tcp window size), or how to handle delays or errors. There are also some advantages because middle boxes who try to be smart and "make TCP" better for you can't really muck with the UDP packets all that much because the applications own protocol of how to handle UDP packets will not likely be know. This is why QUIC is such a big deal -- as a lot of the type of things a middle box might want to -- and do on TCP today -- muck around with are encrypted. So I would not say that UDP is fast because it is not reliable, it is fast because it can allow a programmer to exploit the network in a more efficient way than TCP can for a specific type of data being transferred. There are many reliable UDP based protocols that achieve faster speeds than TCP in different situations.
- peterwwillis 8y agoIt'd be interesting to modify this or a similar program to work with rsync
- deleted 8y ago[deleted]