UDP не гарантирует, что данный пакет был фактически получен, поэтому кодирование того, что вы передаете как «отличие от последнего времени», проблематично - вы не можете знать , что ваш коллега имеет ту же идею как вы о том, что "последний раз" был . По сути, вам придется создать некоторые накладные расходы поверх UDP, чтобы проверить, какие пакеты были получены (пометить каждый пакет уникальным идентификатором) - все, кто пытался пойти по этому пути, согласятся, что чаще всего вы обнаруживаете, что больше или меньше дублирования потоковой инфраструктуры TCP поверх UDP ... только, скорее всего, не так надежно и хорошо развито (хотя по общему признанию иногда вы можете воспользоваться очень особыми характеристиками ваших полезных нагрузок, чтобы получить некоторое скромное преимущество по сравнению с простым товаром) старый ПТС).
Ваша передача должна быть односторонней, от отправителя к получателю? Если это так (то есть, для получателя неприемлемо отправлять подтверждения или повторные передачи), то в действительности вы мало что можете сделать в этом направлении. Одна вещь, которая приходит на ум: если нормально, что получатель какое-то время не синхронизирован, отправитель может отправить два вида пакетов - один с полным изображением текущего значения структуры и идентифицирующим уникальный тег, отправляемый, по крайней мере, каждые (скажем) 5 минут (поэтому реально получатель может быть не синхронизирован до 15 минут, если пропустит два из этих «больших пакетов»); один только с обновлением (diff) последнего «большого пакета», включая идентификационный уникальный тег большого пакета и (например) версию XOR с кодированной длиной серии, о которой вы упомянули.
Конечно, после подготовки версии, закодированной по длине прогона, сервер сравнивает свой размер с размером всей структуры и отправляет только дельта-тип пакета, если экономия является существенной, в противном случае это может также произойти. отправьте большой пакет немного раньше, чем нужно (повышение надежности). Полученный будет отслеживать последний уникальный уникальный тег большого пакета, который он получил, и применяет только дельты, которые относятся к нему (помогает против пропущенных пакетов и пакетов, доставленных не по порядку, в зависимости от того, насколько сложным вы хотите сделать своего клиента).
Необходимость управления версиями и c, в зависимости от того, что именно вы имеете в виду (будут ли отправители и получатели с различными идеями о том, как должен выглядеть макет структуры C структуры, регулярно общаться? Как они сообщают о том, какие версии известны обоим? И т. Д.) , добавит еще одну вселенную осложнений, но это действительно другой вопрос, и ваш основной вопрос, кратко изложенный в заголовке, уже достаточно большой; -).
Если вы можете позволить себе время от времени отправлять мета-сообщения от получателя обратно отправителю (подтверждение или запрос на повторную отправку), то в зависимости от различных числовых параметров в игре вы можете разработать разные стратегии. Я подозреваю, что acks должен быть довольно частым, чтобы делать много хорошего, поэтому запрос на повторную отправку большого пакета (либо конкретно идентифицированного, либо «того, что у вас есть, что является самым свежим») может быть лучшей мета-стратегией, чтобы отбросить пространство опций (что в противном случае грозит взорваться ;-). Если это так, то отправитель может быть в блаженном неведении относительно любой стратегии, которую использует получатель, чтобы запросить повторную отправку большого пакета, и вы можете экспериментировать на стороне получателя с различными такими стратегиями без необходимости повторного развертывания отправителя.
Трудно предложить гораздо больше помощи без каких-либо подробностей, т. Е. Хотя бы приблизительных чисел для всех числовых параметров - размеров пакетов, частоты отправки, как долго допустимо, чтобы отправитель не синхронизировался с получателем набор параметров сети и т. д. Но я надеюсь, что этот несколько общий анализ и предложения все еще помогут.