Перевод Int32 в ushort и обратно

Насколько "больше" 65535 вам нужно? Вы всегда можете просто добавить несколько битов из своего «байтового поля» в качестве старших битов идентификатора. Всего 2 бита дадут вам 262 143, 3 бита - 524 287.

Я могу придумать еще несколько вариантов:

В базе данных глобально меньше 65536 записей? Если это так, то вы можете поддерживать таблицу сопоставления, которая не связана с состоянием сеанса, но является постоянной частью приложения.

Неужели большинство записей в индексах меньше, скажем, 50 000? В этом случае вы можете напрямую сопоставить такие значения и использовать карту, связанную с сеансом, для оставшихся.

Если сохранение таких данных сеанса является проблемой и количество клиентов достаточно мало, вы можете включить привязку клиент / сеанс и сохранить карту локально для сервера.

Если это не веб-приложение, вы можете поддерживать карту на самом клиенте.

Я не вижу никакого алгоритмического способа избежать столкновений - я подозреваю, что вы всегда можете найти примеры, которые бы столкнулись.

Относительно подхода 2:

Ваш второй подход в значительной степени зависит от того, как работает NAT. Каждый клиент TCP / UDP в локальной сети имеет до 65535 используемых портов (кроме порта 0) и частный IP-адрес. Маршрутизатор знает только один общедоступный IP-адрес. Поскольку два клиента могут иметь порт источника 300, он не может просто заменить частный IP-адрес на общедоступный, что может вызвать коллизии. Таким образом, он заменяет IP и «транслирует» порт (NAT: сетевой адрес Перевод). По возвращении он переводит порт обратно и снова заменяет общедоступный частным IP-адресом, прежде чем пересылать пакет обратно. Вы бы больше ничего не делали. Однако маршрутизаторы хранят эту информацию в памяти - и они не слишком медленные при выполнении NAT (компании с сотнями компьютеров иногда подключаются к Интернету через NAT, и в большинстве случаев замедление практически не заметно). Вы говорите, что хотите проводить до тысячи транзакций в секунду, но сколько клиентов будет? Поскольку это в основном будет определять размер памяти, необходимой для резервного копирования сопоставлений. Если клиентов не слишком много, вы можете сохранить сопоставление с отсортированной таблицей в памяти, в этом случае скорость будет наименьшей проблемой (таблица становится больше, а на сервере не хватает памяти).

Что мне немного непонятно, так это то, что вы однажды сказали

Fortunately the client only has about 20 or so instances of things with these IDs - let's call them packages - at any given time and it only needs to have them unique amongst local siblings.

но потом ты говоришь

Some IDs less than 65535 may still be in play on a given client at any time due to non-expiration.

Думаю, под вторым утверждением вы, вероятно, имели в виду, что если клиент запрашивает идентификатор 65536, у него все еще могут быть идентификаторы ниже 65535, а они могут быть даже (скажем) 20. Дело не в том, что клиент обрабатывает идентификаторы в прямой порядок, правда? Таким образом, вы не можете сказать, что только потому, что он теперь запросил 65536, он может иметь несколько меньшие значения, но, конечно, не в диапазоне 1-1000, верно? На самом деле он может содержать ссылку на 20, 90, 2005 и 41238 и по-прежнему превышать 65535, вы это имели в виду?

Мне лично ваш второй подход нравится больше, чем третий, так как в любом случае легче избежать столкновения, а обратный перевод числа - простая и простая операция. Хотя сомневаюсь, что ваш третий подход может работать в долгосрочной перспективе. Хорошо, у вас может быть байт для хранения того, как часто вы вычитали 2 ^ 16 из числа. Однако вы можете вычесть только 117 * 2 ^ 16 как самые большие числа. Что вы будете делать, если цифры превысят это число? Используя другой алгоритм, который не вычитает, но что делает? Делить? Биты сдвига? В этом случае вы теряете детализацию, это означает, что этот алгоритм больше не может использовать ударить для любого возможного числа (он будет делать большие скачки). Если бы было так просто применить волшебную функцию трансляции к 32 битам, чтобы сделать из нее 16 бит (+ один дополнительный байт), а затем просто преобразовать ее обратно, угадайте, что каждый метод сжатия в этом мире использовал бы ее, как мог, нет независимо от того, каким было 32-битное число, всегда сжимайте его до 24 бит (16 бит + один байт). Это было бы волшебством. Невозможно упаковать 32 бита в 24 бита, а также упаковать всю логику, как преобразовать его обратно в него. Вам понадобится внешнее хранилище, что возвращает нас ко второму подходу. Это единственный подход, который будет работать, и он будет работать для каждого числа в 32-битном диапазоне чисел.