IHttpSendFileFeature provided by Transport

[tmds]

Sending files can be offloaded to the kernel. The Transport can expose this as a sendfile feature.

Some implementations support encrypting (BSD sendfile, Http.Sys) while others do not (Linux sendfile, corefx Socket).

#1593 tracks Transport independent implementation.

cc @davidfowl @Tratcher @Drawaes @benaadams

[tmds]

Does someone have an idea of how this might work? I'm pondering about it, but I can't figure out how the the pipeline data flow and the sendfile system call work together.

[Tratcher]

SendFile bypasses the normal datastream and writes directly to the socket, though it should flush the datastream fist to ensure proper ordering. Higher layers that would behave incorrectly if bypassed (SSL, caching, etc.) should fake the feature by wrapping the datastream, or remove the feature.

[tmds]

@Tratcher makes sense. SendFile implementation would indeed need to flush the datastream, also it also needs to take into account the Connection lifetime. HTTP 2 is also a higher layer, right?

[benaadams]

HTTP/2 is on HTTPS (for all practical purposes). Is OS sendfile non-blocking/async, e.g. will it callback on send complete so the connection can be resumed for keepalive?

[tmds]

(for all practical purposes)

I've heard that too. Hard to imagine no-one wants to cut out the cost of encryption for some use-cases, but I'm no expert.

Is OS sendfile non-blocking/async, e.g. will it callback on send complete so the connection can be resumed for keepalive?

On Linux, it's a blocking call which returns when the file is sent. nginx offloads sendfile to a threadpool to avoid blocking the main worker thread.
Once the sendfile call returns, the connection can be used for other requests.

[Tratcher]

SendFile is async on Windows. We avoided implemented it in the past due to the sync API on linux.

[davidfowl]

This doesn't work well at the transport layer.

[tmds]

This doesn't work well at the transport layer.

@davidfowl In the Pipelines API review issue you said this was Kestrel specific. Now you say it doesn't work at the Transport layer. Is the conclusion, Kestrel/Pipelines cannot leverage the sendfile system call?

[davidfowl]

IHttpSendFileFeature is ASP.NET specific.

Is the conclusion, Kestrel/Pipelines cannot leverage the sendfile system call?

Don't conflate pipelines the abstraction with how we use it in Kestrel. The way Kestrel interacts with the transport layer via pipelines this isn't a good fit. The IHttpSendFileFeature needs to live closer to Kestrel than it does to the transport. You're essentially bypassing the pipe completely and writing directly to via the socket. This by passes all connection filters (connection middleware) which flat out breaks scenarios like SSL (and logging but that's just logging). The transport should remain a dumb byte pump that kestrel sends data over.

[tmds]

I understand the Transport can't completely implement IHttpSendFileFeature. I think it has a role to play since it is abstracting the network implementation.

If you think its possible for Kestrel to leverage sendfile at some abstraction, please keep an open issue for it.

[davidfowl]

At the moment, I don't see a reason to keep an issue open as we haven't designed anything and aren't currently thinking about it. If you'd like to spike something then I think that would be fine.