pixik: Основная проблема, что все, что вы пишете, кажется немного костылем на костыле, потому что вы не описали глобальный смысл этого.
У вас связь между двумя точками организована по модему, и нет возможности связать эти две точки, а инфу нужно гнать? Или у вас странное устройство, которое может только получать данные по ком-порту, а эти данные нужно гнать дальше?
Ну то есть, пока вы не опишите самый верхний уровень возникновения проблемы, советы будут очень "нишевыми", и очень вряд ли кто-то подскажет больше, чем вы уже знаете, разве что он сталкивался именно с такой же проблемой как у вас.
А зачем писать данные в файл?
Почему нельзя писать данные в разные файлы, и передавать по модему уже завершенные? При этом их можно сжать, а если очень надо, объединить с той стороны.
Что это за данные и почему нельзя передавать данные не файлом а другим способом, который больше подходит под передачу фрагментами?
Серожа none: частота работы шины упирается не в это, а в технологический процесс изготовления чипов.
Иначе почему в 90е годы скорость света упиралась в 5-12 мегагерц а сейчас в 4-6 гигагерц?
andrewjabber: mamkaololosha:
Процессоры улучшаются, ускоряются, новые инструкции. Появляются новые возможности - GPU, многопоточность, на порядки вырос объем доступной для анализа памяти.
Кто-бы мог себе представить рабочий кодек x264 в 90-м году на 8086 ?
Коллизии хешей также представляют проблемы, ибо биг-дата, размеры хеш-массивов все больше и больше.
Уже который год хотят архиватор, который юзает GPU (хотя это практически вряд ли имеет смысл), но мало ли.
Филипп Поликаренков: ну так тем более, вы не видите смысла в программировании и в практическом применении ваших знаний на практике. И как только встречается рутинное, неудобное для мозга действие, вы забрасываете. Значит просто не ваше.
Saboteur
@saboteur_kiev Куратор тега Разработка игр
Сервер будет отрабатывать действия по степени их реальной длительности. Если у сервера указано, что переход из комнаты в комнату длится два тика, значит следующий переход он будет выполнять через два тика.
При этом вполне можно добавить команду "стоп", при получении которой сервер сразу очищает весь буфер команд игрока, и ставит статус "стоп".
Очередной "тик" сервера, когда он пробегает по всем действиям игрокам, сервер увидит статус стоп и прервет текущий action игрока согласно очередности.
Что находится по вашей ссылке четко не ясно, но там не совсем то. Там вообще чуть ли не браузерка комнатная. В этом случае все делается иначе.
Пошаговая стратегия, в которой каждый игрок отправляет свои действия. Сервер может просчитывать какие-то действия сразу автоматом (например бои в порядке очереди), а например сами постройки и сбор ресурсов не считает в принципе. Для этого используется схема таймстампов и расчет по последнему обновлению.
Пример такой:
я захожу в казармы и заказываю постройку 1000 лучников. Каждый лучник строится 0.5 секунды. В момент заказа, на сервер отправлена команда 1000 лучников. Сервер получает ее, проверяет ресурсы, и записывает время начала выполнения.
Клиент со стороны игрока может сам по себе рисовать новых юнитов, согласно своим рассчетам, периодически отправляя запросы на обновление информации к серверу.
В момент такого запроса, сервер сравнивает прошлое время с текущим, высчитывает сколько должно было быть построено юнитов, и добавляет их.
Таким образом, расчеты делаются не каждые полсекунды для каждого игрока, а гораздо реже.
Если игрок выйдет из игры - расчет вообще будет выполнен при следующем логине. Либо если другой игрок зайдет в эту комнату (то есть не важно кто вызвал апдейт, главное что расчет информации будет идти строго по запросу). Так снижается нагрузка на сервер от регулярных расчетов всего и всея, но тут не требуется идеальная синхронность.
Взять популярные игры вконтактиках, с онлайном до 100к игроков, там даже начало боев часто определяется "примерно в пределах от 1 сек до 1 мин".
То есть не существует идеальной синхронизации для многих игроков.
Та же линейка, в момент осады (то есть пиковое время, когда в зоне видимости 2-4 тысячи человек), начинала жутко тормозить, а передавались исключительно клики мышкой, ибо в линейке нет такого, как движения стрелочкой, только клик "бежать по координатам x,y", кастануть в игрока ID xx скиллом yy
А если ваш сервер выполняет действи исключительно по сигналу от игрока, то это неверно - по сигналу от игрока, на сервере должно инициироваться действие, но выполняться оно должно в своем цикле.
Например предположим что-нибудь простенькое, например текстовую игру в чате.
Игрок пишет команды "идти влево", "идти влево", "идти вниз". Он их может написать и отправить практически одновременно, но на сервере скорость "хотьбы" должна быть определена.
Например на сервере установлен свой цикл с частотой 2 раза в секунду, когда он обрабатывает действия в мире. И когда он перебирает всех игроков с их текущим экшеном, он просто видит на какой стадии игрок. В тот момент, когда игрок завершил свободную команду, сервер смотрит в буфер игрока и начинает выполнять следующую. А сам поток коннекшена с игроком, может тольпо принять в буфер эту команду. Ну или очистить его, если игрок напишет например "стоп". Но игрок не должен пробежать все три позиции именно в момент получения этих команд сервером.
Как-то так.
Дальше - думайте сами, игры разные, случаи разные...
Я еще помню doom2 целиком на tcp, который шел со скоростью самого медленного игрока в сети.
Saboteur
@saboteur_kiev Куратор тега Разработка игр
Alexey Lizurchik: В сервере всегда есть свой цикл, по которому происходит процесс. У вас мобы как бегают? Мгновенно, или с определенной скоростью? У вас снаряды как летят - мгновенно, или от них можно увернуться? Как промежутки полета вычисляются?
В той же Eve Online существует даже замедление игрового времени, если игроков в системе становится слишком много, чтобы адекватно успевать синхронизировать всех участников.
Saboteur
@saboteur_kiev Куратор тега Разработка игр
от пользователей к серверу - tcp, от сервера к пользователям - udp
таким образом, сервер всегда с определенной частотой рассылает всем игрокам текущий статус, и этот статус должен быть не инкрементивным а цельным. Если игрок не успеет принять какой-то пакет, это не страшно - в следующем пакете нагонит, ну а сервер не ждет от каждого игрока подтверждение, что пакет принят, таким образом сам по себе не тормозит с игровыми тиками.
А игроки отправляют серверу с подтверждением по TCP, таким образом клиент игрока точно знает, что уже было отправлено на сервер с подтверждением, и может отрисовывать экшн, или наоборот залагать, но не влияя на остальных игроков.
dvomaks: ну а что такого может испортить то, что в массив попадет странная информация? Пока ее никто не обрабатывает ничем, ничего она не сможет сделать.
Вам же верно сказали, что надо смотреть где оно применяется, и чаще всего это в виде sql/exec injection
