3.9. Соображения уменьшения трафика
Сервер должен (MUST) обеспечить, чтобы количество сообщений, генерируемых для обновления содержимого каталога клиента, не превышало количества записей, находящихся в этом содержимом. Хотя для серверов не выдвигается никаких требований по поддержанию информации об истории изменений, если на сервере имеется история изменений в объёме, достаточном для того, чтобы позволить ему достоверно определить, какие записи из предыдущей клиентской копии не присутствуют больше в содержимом каталога, и если количество таких записей меньше или равно количеству неизменённых записей, серверу следует (SHOULD) генерировать сообщения об удалении записей вместо сообщений о наличии записей (смотрите раздел 3.3.2).
Когда количества поддерживаемой на сервере информации об истории изменений недостаточно для обслуживания клиентов, которые редко выполняют операцию Sync в режиме refreshOnly, вполне вероятно, что к моменту повторного подключения таких клиентов у данного сервера будет неполная информация об истории изменений (например, в связи с её усечением).
Серверу не следует (SHOULD NOT) прибегать к полной перезагрузке, если информации об истории изменений недостаточно для генерации сообщений об удалении записей. Для приведения клиентской копии в текущее состояние серверу следует (SHOULD) генерировать либо только сообщения о наличии записей, либо сообщения о наличии записей, за которыми следуют сообщения об удалении записей. В последнем случае сообщения о наличии записей приводят клиентскую копию в состояние, покрываемое хранящейся на сервере информацией об истории изменений.
Серверу следует (SHOULD) поддерживать информацию (текущую или историческую) о состоянии, такую как отметка времени последнего изменения содержимого каталога в целом, достаточную для того, чтобы определить, что с момента предоставления обновления содержимого каталога не было сделано никаких изменений в этом содержимом, и, если изменений не было сделано, генерировать ноль сообщений об удалении записей вместо сообщений о наличии записей.
Серверу не следует (SHOULD NOT) использовать информацию об истории изменений, если её использование не уменьшает количества трафика синхронизации или если её использование может привести к раскрытию конфиденциальной информации, которую не разрешено получать клиенту.
Тем, кто занимается разработкой сервера, следует также рассмотреть вопросы уменьшения трафика, охватывающие несколько операций Sync в рамках сессии. Как сказано в разделе 3.8, сервер может вернуть e-syncRefreshRequired если он определил, что перезагрузка будет более эффективна, чем продолжение посылки обновлений в рамках текущей операции. Если поле reloadHint в элементе управления Sync Request установленов в TRUE, сервер может инициировать перезагрузку, не давая клиенту указания запросить перезагрузку.