Это будет немного абстрактный вопрос, так как я даже не знаю, есть ли какие-нибудь подобные разработки.
Учитывая, что у нас есть приложение, которое пытается доставить текстовые данные из точки A в точку B. A и B находятся довольно далеко, поэтому размер данных оказывает значительное влияние на все важные метрики, которые мы хотим оптимизировать (скорость, задержка и пропускная способность). Первое, что приходит на ум, - это сжатие, но сжатие не так эффективно, когда нам нужно сжать много маленьких сообщений, но очень эффективно, когда размер сжатых данных значителен.
У меня нет опыта работы с алгоритмами сжатия, но я понимаю, что чем больше ввод, тем лучше может быть степень сжатия, поскольку существует большая вероятность повторения фрагментов и вещей, которые можно оптимизировать.
Еще один способ, которым мы могли бы пойти, - это пакетирование, ожидая в течение некоторого периода времени N и собирая все крошечные сообщения и создавая одно сжатое большое, у нас может быть хорошая степень сжатия, но мы пожертвуем задержкой, сообщение, которое приходит первым, займет ненужную задержку в размере Н.
Решение, которое я ищу, выглядит примерно так: когда алгоритм сжатия пересекает набор данных, он, вероятно, имеет какой-то словарь вещей, которые, как он знает, можно оптимизировать. Этот словарь отбрасывается каждый раз, когда мы заканчиваем сжатие, и всегда отправляется с сообщением в B.
rawMsg -> [dictionary|compressedPayload] -> send to B
однако, если бы мы могли хранить этот словарь в памяти и отправлять его только тогда, когда в нем есть изменения, это означало бы, что мы можем эффективно сжимать даже небольшие сообщения и избегать отправки словаря на другой конец каждый раз ...
rawMsg -> compress(existingDictrionaryOfSomeVersion, rawMsg) -> [dictionaryVersion|compressedPayload] -> send to B
теперь очевидно, что здесь предполагается, что B также сохранит экземпляр словаря и продолжит его обновлять, когда появится более новая версия.
Обратите внимание, что именно это уже происходит с такими протоколами, как protobuf или fix (в финансовых приложениях). С любым сообщением у вас есть схема (словарь), и она доступна на обоих концах, а затем вы просто отправляете необработанные двоичные данные, эффективно и быстро, но ваша схема фиксированная и неизменная.
Я ищу что-то, что можно использовать для текста в произвольной форме.
Есть ли какая-нибудь технология, позволяющая это сделать (без фиксированной схемы)?
