aidynchikчто ID не перевалит за диапазон

есть

твой клиент РАЗУМЕЕТСЯ должен отказываться от перехода через диапазон и должен всегда получать от сервера два диапазона: текущий и следующий

"double buffering" и "Page flipping" - это же реально основы!

Dimitry SibiryakovНо лично я рекомендую-таки GUID.

типовая ошибка 90-х: звуковые драйвера кажется Opti не встают на компьютер, накотором стоит fineReader

таки да, они заняли одинаковый GUID

да я собственно уже написал все выше

любая работа, которая должна идти без задержек, делается минимум в ДВА выходный буфера

что ты музыку слушаешь, что кино смотришь, что в стрелялку играешь

у тебя есть один буфер, который пошёл в работу (показывается на экране, играет в наушниках/колонках и т.д.), и второй буфер, которой наполняют (распаковывают mp3, строят сцену из полигонов, ...).

в тот момент когда пора (буфер построен И пришло время закончить первый буфер) делается переключение, буфера меняются местами (нужно всего лишь два указателя местами поменять). Теперь второй буфер идёт в работу (на экран, колонки, etc), а первый очищается и начинает заполняться данными. Потом они снова меняются местами и т.д.

раньше на "пузатых" мониторах переключение буферов подгадывали к V-Sync, естественной паузе в работе любого ЭЛТ-монитора, так эта настройка до сих пор сохранилась

----------------------

ещё частный случай - сохранение любого файла, например посмотри как zip/7-zip/rar изменяют архивы. Они старый файл не убивают, они рядом создают временный файл и начинают в нём создавтаь новый, исправленный архив. И только если это получилось - тогда они делают переключение (переименование двух файлов, а ПОСЛЕ успешного переименования - удаление старого архива).

пример школьного подхода, с одним буфером, - S.T.A.L.K.E.R. - если игра крэшилась во время сохранения (а это было часто), то у тебя старого сейва УЖЕ нет, а нового ЕЩЁ нет

-----------------

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

Старый плюшевый мишка,

ну мне этот подход тоже больше делается, например в нём точка в принципе независит от сервера, даже если они год сихнронизироваться не могут. Т.е. точку можно продавать отдельно, а много-точку уже потом продать кому надо.

но минус этого подхода - что делать если точки сливаются/делятся, как историчность соблюсти ? Надо где-то хранить историю связей разных ID_Point? а чем это отличается от хранения историй диапазонов? Как-то так.

Ariochбольше делается

ээээ, нравится, конечно же

минус диапазонов - нужно организовать вне-транзакционный "прыжок генератора" со старого диапазона на новый.

можно пытаться предугадать время и прыгнуть заранее, оставив десяток-другой последних ID незаполненными

или брать не напрямую из генератора, а из UDF с межпоточной и межпроцессной блокировкой

но КМК естественней всего диапазоны ложатся на трёхзвенку, а не на клиент-сервер

aidynchik,

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

или я - плохая девочка, где-то умыкнул твой софт центра, поставил фейковый сервер, а потом подкупил уборщиц на точке, чтобы они её перенастроили с моим сервером общаться вместо настоящего?

продумывай схему, как именно ты будешь распространять точки и сервера так, чтобы они с гарантией и находили и аутентифицировали(проверяли) друг друга. ID будет всего лишь естественной частью аутентификации, получишь его автоматически

Отдельный монстры даже программу хранять в БД в блобах, чтобы обновлять автоматически.

IMHO изврат, но тогда правильной точке ты высылаешь загрузчик с данными по аутентификации

загрузчик цепляется к серверу, предъявляет свой "паспорт", проверяет "паспорт" сервера, и если всё хорошо - цепляется к БД и выкачивает программу.

Впрочем, выставлять Firebird напрямую в сеть считается вродеж плохим тоном, так что думай о 3-звёнке :-)
Или о виртуальной сети проброшенной через интернет

www.ibase.ru/zebedee/
www.sql.ru/forum/130264/zebedee

aidynchikно защиту поставлю разумеется

тогда и вопрос с ID решится автоматически, как часть защиты

Мимопроходящий,

www.ibase.ru/openvpn/ -> 404

Симонов Денисесли будет 3-х звенка то не фиг парится по поводу подмены БД, путь этим заморачивается промежуточное звено

я имею в виду 3-звенку _внутри_ каждой оконечной точки

а вопрос подмены - это _между_ точкой и центром

Симонов ДенисПричём сами диапазоны пущай вычисляются на принимающей стороне

на сервере в любом случае тоже надо имет список диапазонов, проверять валидность ID

Мимопроходящий,

насколько понимаю, плюс и минус зибиди - это туннельной точка-точка шифрование конкретного соединения

а VPN - это всё же склеивание обеих LAN, более сложная и мощная схема.
иногда это минус, когда я хочу именно пробросить один конкретный канал, типа port forwarding, а не настроить раутинг для всех программ во всей подсети