4 ms·
Imagine you're not bandwidth-limited and you want to transfer multiple files. One is on Disk A, one is on Disk B, one is on NFS, etc. Sending them all at once e
by zrm 10y ago
Imagine you're not bandwidth-limited and you want to transfer multiple files. One is on Disk A, one is on Disk B, one is on NFS, etc. Sending them all at once exploits parallelism, and the transfer on the faster disk doesn't get stuck behind the transfer on the slower disk.
One file per connection also makes the implementation simpler. If you want to use one TCP connection for multiple transfers then you need some kind of a header and logic to determine start and end of file, and new control messages get delayed in queue behind already-buffered data. If you have a data connection for exactly one file then you just call sendfile() and then close().
And transferring a file with active mode FTP looks like this:
Client -> Server: I want to transfer a file, connect to 1.2.3.4:12345.
Server -> Client: TCP SYN to 1.2.3.4:12345
Passive mode requires another half trip latency:
Client -> Server: I want to transfer a file, passive mode.
Server -> Client: OK, connect to 4.3.2.1:54321.
Client -> Server: TCP SYN to 4.3.2.1:54321
A different protocol could avoid the extra latency by having the server always use the same port, but that makes the implementation more complicated again. The server could get a data connection from the client before it gets the associated control message. Now it has to deal with matching them up, another timeout in case the control message never arrives, etc.
It's possible to run FTP over TLS. Hardly anybody does that because it makes the NAT problem worse, because then the NAT device can't even snoop the control connection and map the port. FTP programs could fix this by mapping the data port using something like NAT-PMP or PCP, but I'm not aware of any that currently do.
- comex 10y agoUnfortunately, these days crypto really is a mandatory feature, and sendfile doesn't work with TLS anyway. (IMO it should - secure communication should be an OS-level service rather than requiring each application to figure it out, just like the OS provides TCP rather than requiring each application to implement reliable connections - but that's another story.)
- geofft 10y agoHmmm. sendfile is great because it lets the kernel arrange for DMA straight from disk to the network card, in addition to bypassing context switches and copies to and from userspace buffers. If the kernel gains an SSL stack (the encrypted version of the file is going to be different for each connection), you can't DMA and you'll need to make copies into kernelspace buffers to do the encryption on. Is skipping the context switch enough to make a meaningful performance different?
- feld 10y agoYes. And I believe Solaris was the first to discover this. Here's a paper Netflix put out covering their first attempt. Measurable gains, hopefully more coming in the future. https://openconnect.netflix.com/publications/asiabsd_2015_tls.pdf https://openconnect.netflix.com/publications/asiabsd_2015_tl... edit: check this post first https://news.ycombinator.com/item?id=12037748 https://news.ycombinator.com/item?id=12037748
- lomnakkus 10y ago> Is skipping the context switch enough to make a meaningful performance different? Only in (very) high-bandwidth cases and (maybe!) for low-power cases. For most things it's just added complexity for no benefit.