MirrorHub/construct
0
0
Fork 0
mirror of https://github.com/matrix-construct/construct synced 2025-01-14 00:34:18 +01:00
Code Issues Releases Wiki Activity

modules/client/sync: Add comments to main frame.

Browse source
This commit is contained in:
Jason Volk 2019-07-06 20:19:08 -07:00
parent 18f07b6378
commit 5c8425d047
1 changed files with 47 additions and 11 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

58
modules/client/sync.cc
View file

@ -207,6 +207,10 @@ ircd::m::sync::handle_get(client &client,
// Keep state for statistics of this sync here on the stack.
stats stats;
// The ubiquitous /sync data object is constructed on the stack here.
// This is the main state structure for the sync::item iteration which
// composes the /sync response.
data data
{
request.user_id,
@ -217,6 +221,7 @@ ircd::m::sync::handle_get(client &client,
args.filter_id
};
// Determine if this is an initial-sync request.
const bool initial_sync
{
range.first == 0UL
@ -235,6 +240,12 @@ ircd::m::sync::handle_get(client &client,
client, http::OK, buffer_size
};
// Start the JSON stream for this response. As the sync items are iterated
// the supplied response buffer will be flushed out to the supplied
// callback; in this case, both are provided by the chunked encoding
// response. Each flush will create and send a chunk containing in-progress
// JSON. This will yield the ircd::ctx as this chunk is copied to the
// kernel's TCP buffer, providing flow control for the sync composition.
json::stack out
{
response.buf,
@ -248,36 +259,61 @@ ircd::m::sync::handle_get(client &client,
log, "request %s", loghead(data)
};
// Pre-determine if longpoll sync mode should be used. This may
// indicate false now but after conducting a linear or even polylog
// sync if we don't find any events for the client then we might
// longpoll later.
const bool should_longpoll
{
// longpoll can be disabled by a conf item (for developers).
longpoll_enable &&
// polylog-phased sync and longpoll are totally exclusive.
!data.phased &&
// initial_sync cannot hang on a longpoll otherwise bad things clients
!initial_sync &&
// When the since token is in advance of the vm sequence number
// there's no events to consider for a sync.
range.first > vm::sequence::retired
};
// Determine if linear sync mode should be used. If this is not used, and
// longpoll mode is not used, then polylog mode must be used.
const bool should_linear
{
// There is a conf item (for developers) to force polylog mode.
!polylog_only &&
// polylog-phased sync and linear are totally exclusive.
!data.phased &&
// If longpoll was already determined there's no need for linear
!should_longpoll &&
!bool(polylog_only) &&
// The primary condition for a linear sync is the number of events
// in the range being considered by the sync. That threshold is
// supplied by a conf item.
range.second - range.first <= size_t(linear_delta_max)
};
const bool shortpolled
// Determine if an empty sync response should be returned to the user.
// This is done by actually performing the sync operation based on the
// mode decided. The return value from the operation will be false if
// no output was generated by the sync operation, indicating we should
// finally send an empty response.
const bool complete
{
should_longpoll?
false:
longpoll::poll(data, args):
should_linear?
linear_handle(data):
polylog_handle(data)
};
// When shortpoll was successful, do nothing else.
if(shortpolled)
return {};
if(longpoll_enable && (!data.phased || initial_sync))
if(longpoll::poll(data, args))
return {};
if(complete)
return response;
const auto &next_batch
{
@ -289,7 +325,7 @@ ircd::m::sync::handle_get(client &client,
// A user-timeout occurred. According to the spec we return a
// 200 with empty fields rather than a 408.
empty_response(data, next_batch);
return {};
return response;
}
void