Update README; 10gig isn't even hard anymore these days, the kernels are so
fast. Andre Tomt verified ~40 Gbit/sec with kTLS on a quadcore 45W Xeon D,
with no particular tuning.
We'd either never time out clients (if the expiry check happened
while they were receiving a request) or time them out too soon
(based on the connection time instead of the time of last request end).
Cuts something like 600 ms away from the initial TLS handshake,
as we kept having unflushed data that would require waiting for
the 200 ms TCP_CORK timer.
In particular, writing Content-Length instead of Content-length fixes a
problem where VLC's HTTP client would hang forever on our responses.
This makes HLS generally work in VLC, although it still starts playing
from the start instead of from the end.
This depends on the new Metacube PTS metadata block, which only
Nageru >= 1.7.2 serves at the moment. Lightly tested with iOS and hls.js;
does not work with VLC and mpv yet.
Do not serialize prebuffering_bytes in StreamProto.
There's no need to do this now that we can't have zombie streams anymore
(to be honest, the reason used to be rather thin already; it probably was
rather unintentional).
Automatically delete streams that are no longer in the configuration file.
Earlier, you had to mark this by setting src=delete, or the stream would linger
on in a sort of half-state; this was meant as a protection against configuration
messup. It has shown not to be that easy to mess this up in practice, so remove
it to make cleanup simpler.
Support Metacube metadata blocks, specifically timestamps.
Allows you to measure latency from encoder to reflector; specifically,
this is useful to figure out if you have a HTTP queue that keeps on
growing indefinitely.
Fix an issue where access.log would have the wrong timestamp.
The refactoring to use monotonic timestamps did not take into account
that the timestamps are used for the access log, so it'd contain
(roughly) time since boot instead of the actual time of day. Fixed by
measuring the offset between the two (although if the clock is wrong
at the time of logging, the connection time will be wrong -- as opposed
to if the clock is wrong at the time of connect, hard to say which is
the better). Reported by Joachim Tingvold.
While we are at it, change some of the timespec functions so that we
get slightly more precise timing in the logs (it could be about a second
off). For cosmetics only.
Add a simple HTTP endpoint that returns a very short string.
The intention is for clients to be able to probe the endpoint
to figure out which server is the fastest. To this end,
it supports CORS headers so that XHR is allowed to differentiate
servers that are down from servers that respond properly.
Allow prebuffer to happen by playing data from the backlog.
This won't reduce the latency (although it shouldn't increase it either, unless
you have extreme bitrate changes), but it should give a picture on screen much
sooner, hopefully getting rid of the “what's going on, why is nothing starting”
feeling.
In the case where we really are in WAITING_KEYFRAME, we will go to
sleep immediately in the state below, but there's also a case
where we could end up directly in SENDING_DATA and don't want to
wait for the stream to get more data to start sending.
add_data_raw() does not change the stream suitability points at all;
it just writes to disk. Thus, we don't need this complicated little dance
to give it multiple blocks.
Track stream start suitability separately for each data block added.
When having queued data, keep the separate stream start suitability flag
for each iovec instead of just storing the index of the last block.
This is a no-op in itself, but it is a prerequisite for tracking it in
the backlog as well, which we want to do to be able to have force_prebuffer
give out older data -- that requires tracking not only the last suitable
starting point, but multiple ones backwards in time.
Also add a TODO to update starting point(s) when the header changes.
Instead of checking that connect times are monotonic, explicitly make them
so if they're not. This seems safest, in case the monotonic clock goes
backwards a small bit (e.g. when changing CPUs). We don't need it for the
serialized case since we explicitly sort those by time; the assert can stay.
Time out clients still in READING_REQUEST after 60 seconds.
Seemingly there are some of these around, and I've seen them eat up
fds in a long-running server. There's some pain in sorting the clients
on deserialization, but apart from that, this ended up being relatively
pain-free and should be efficient enough.
Change the connected time from time_t to timespec.
The primary gain as the code stands is that we become immune to
issues with the clock going backwards etc. in logs (since we can
now use a monotonic timer).
However, the motivating change is that we will soon be implementing request
read timeouts. At that point, not only will the clock data be much more
important to get right, but it will also be nice to have more fine-grained
timestamps to be able to locate clients semi-uniquely in a sorted list.
The motivation is jwPlayer, which for HTTP files expects to be able
to do no prebuffering and just download full speed nevertheless
(as it assumes they are static files, not streams) -- when it cannot,
it shows an ugly icon on top of the stream all the time. So we add
an option for forced prebuffering (three seconds seems to be about
fine) which means we wait sending until we have a pretty big backlog.
Ideally, we would be able to actually send old data instead of just
waiting (which would mean that the client doesn't need the extra wait
at the beginning), but it's complicated with having to remember old
keyframe positions, changed stream headers etc.
projects / cubemap / log