Есть ли программы записи работы java сервера? Для последующего воспроизведения как записи в клиенте

BladeRunner

Знающий
Меценат
Сообщения
1 219
Розыгрыши
0
Репутация
-265
Реакции
464
Баллы
475
Хроники
  1. Interlude
Исходники
Присутствуют
Сборка
любая с исходами
Подскажите, есть ли решения, как логировать полностью всю работу сервера? чтобы потом по имеющимся логам можно было запустить сервер на воспроизведение их, и получить как бы полную видео-запись со всеми данными того, что происходило на сервере. Мне это видится как дополнительный сервис, который для админского персонажа создает проигрывание сервера по записи , при этом можно менять скорость воспроизведения, перематывать, фризить. такая своеобразная "Матрица" получается)
И если нет - кому интересно заморочиться созданием такого на платной основе или как проект на энтузиазме? ))
 
Насколько я понимаю - тебе для твоих экспериментов понадобятся ещё и очень качественные боты, которые будут эмулировать поведение различных групп игроков. Так же надо как-то "ускорять" сам сервер - уменьшать время тиков или вроде того. Для онлайн игры такое моделирование скорее всего не реализуемо де факто - слишком много ресурсов потребует.

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

А сколько? Помнится на заре ла2 на мелке, и даже на еврооффе играли по тарифному инету. И вместе с серфингом в месяц хватало часто 1 гига. Есть инфа, сколько трафика при каком реальном онлайне без трейдеров жрет сервер в месяц?



С телефона ща неудобно, позже раскрою идею. Новичкам везет потому, что они не знают, что чтото считается невозможным или сложным. Я часто слышу это, а потом делаю)
Можешь подскащать средний месячный трафик сервера рыл на 1000 реальных без трейдеров? И может средний обьем трафика на одного?



Можете поподробнее на пальцах обьяснить, для чайника)
Дело не только в тарифике. Т е условно, пакет может состоять из 8 байтов. Но в логе будет условно 10 + 8. 10 - на метку времени, адресата, итд ну а 8 - сам пакет.
Если нужно чисто для понимания, сработала ли идея - лучше уж иметь прямой контакт с профессиональными игроками на проекте, которые смогут дать фидбек, и собирать различные метрики (по типу кд до обновы у класса - после, итд)
 
Дело не только в тарифике. Т е условно, пакет может состоять из 8 байтов. Но в логе будет условно 10 + 8. 10 - на метку времени, адресата, итд ну а 8 - сам пакет.
Если нужно чисто для понимания, сработала ли идея - лучше уж иметь прямой контакт с профессиональными игроками на проекте, которые смогут дать фидбек, и собирать различные метрики (по типу кд до обновы у класса - после, итд)
Мне кажется он хочет моделировать прогрессию игрового мира с заданными параметрами. Типа как механика "ускорения времени" в некоторых оффлайн играх. Чтобы можно было менять разные параметры, "ускорять" мир и смотреть что из этого вышло как в кино.
Живые игроки в таком случае не вариант, потому что потребуется "перематывать" сотни, а может и тысячи часов игрового процесса. Может быть даже параллельно на десятках "серверов".
 
Обложи логами интересующие тебя балансовые моменты и радуйся жизни, не травмируя психику читателей)
Делать что-то сложнее - не стоит свеч
Спасибо, кэп. Так не интересно.
 
Самый идеальный вариант, правда абсолютно не реализуемый в обозримом будущем - это снапшоты всего процесса сервера при любом изменении в нем, т.е. по сути чуть ли не каждый тик процессора, и затем возможность с любой нужной скоростью воспроизводить эти снапшоты :)
 
Можешь подскащать средний месячный трафик сервера рыл на 1000 реальных без трейдеров? И может средний обьем трафика на одного?
Причем тут трафик? Я тебе сейчас не про трафик говорю.

Новичкам везет потому, что они не знают, что чтото считается невозможным или сложным. Я часто слышу это, а потом делаю)
Я короче написал тебе оооочень большой пост, но стер его, т.к понимаю, что наверное это бессмыслено. Ты просто сейчас условно у группы конструкторов ракет, спрашиваешь, а можно ли построить ракету, ну скажем из тараканов? Тебе говорят, что в принципе, в теории, ее можно построить, но получится хуета, но ни один здравомыслящий человек не станет строить ракету из тараканов, даже если у него ПРЯМ 3.14здец НЕТ ТОРМОЗОВ в башке и он готов вписываться в вообще произвольную ебату. Так и тут. В теории можно, на практике никто на это не подпишется.
 
Дело не только в тарифике. Т е условно, пакет может состоять из 8 байтов. Но в логе будет условно 10 + 8. 10 - на метку времени, адресата, итд ну а 8 - сам пакет.
Если нужно чисто для понимания, сработала ли идея - лучше уж иметь прямой контакт с профессиональными игроками на проекте, которые смогут дать фидбек, и собирать различные метрики (по типу кд до обновы у класса - после, итд)
Я бы не советовал сохранять пакеты. Так как каждый пакет будет иметь (X,Y и может даже Z) координаты, откуда его пересылали. Простo так все записать можно, но и проигрывать запись будет можно только с конца до начала (нельзя например проигрывать в обратную сторонy, или же просто поставить паузу в движении). Хотя я согласен, что вместо постройки системы можно простo узнать что нужно от такой грандиозной идеи. Можно паример просто научиться пользоваться дебаггером :)
 
Самый идеальный вариант, правда абсолютно не реализуемый в обозримом будущем - это снапшоты всего процесса сервера при любом изменении в нем, т.е. по сути чуть ли не каждый тик процессора, и затем возможность с любой нужной скоростью воспроизводить эти снапшоты :)

Не нужен идеальный) есть идеи по хорошему рабочему?)

Причем тут трафик? Я тебе сейчас не про трафик говорю.


Я короче написал тебе оооочень большой пост, но стер его, т.к понимаю, что наверное это бессмыслено. Ты просто сейчас условно у группы конструкторов ракет, спрашиваешь, а можно ли построить ракету, ну скажем из тараканов? Тебе говорят, что в принципе, в теории, ее можно построить, но получится хуета, но ни один здравомыслящий человек не станет строить ракету из тараканов, даже если у него ПРЯМ 3.14здец НЕТ ТОРМОЗОВ в башке и он готов вписываться в вообще произвольную ебату. Так и тут. В теории можно, на практике никто на это не подпишется.

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

Не хочу как-то усомнится в твоем профессионализме, но часто я делал то, что мне говорили невозможно спецы с десятилетиями опыта. Просто не стандартным путем. Может ты привык к одному видению процессов из многолетнего опыта, а тут требуется нестандартный подход
Ну пожалста, не надо инженеру из бауманки рассказывать про ракеты из тараканов, когда профессор, проектирующий ракеты для впк, обсуждал со мной их геометрию, авось интерную мысль подкину))
Зачем стер большой пост? Если человек действительно разбирается, он всегда может обьяснить человеку, даже новичку, простым языком))) и сам себя не жалеешь, стер свою работу(((


Я бы не советовал сохранять пакеты. Так как каждый пакет будет иметь (X,Y и может даже Z) координаты, откуда его пересылали. Простo так все записать можно, но и проигрывать запись будет можно только с конца до начала (нельзя например проигрывать в обратную сторонy, или же просто поставить паузу в движении). Хотя я согласен, что вместо постройки системы можно простo узнать что нужно от такой грандиозной идеи. Можно паример просто научиться пользоваться дебаггером :)

Про какие пакеты идет речь? От клиента серверу, или от сервера с обработанным положением чара и разрешенным действием? Может от обратного восстановить траекторию? Нам по сути нужны вродемвекторы и временные реперные точки, а не скрин сервера каждую секунду или тик сервера. Я просто пока не пойму причины, почему реплей можно сделать, а это - нет. По сути же клиент в реплее частично эмулирует действия сервера. Надо просто в логике ядра сервера задать отдельные сиквенции для воспроизведения реплея, и для спектатора

Зы: промотку, изменение скорости и тд- это дело десятое и делается потом костылями. Главное сделать проигрывание, и желательно- паузу.
 
Последнее редактирование:
Про какие пакеты идет речь? От клиента серверу, или от сервера с обработанным положением чара и разрешенным действием? Может от обратного восстановить траекторию? Нам по сути нужны вродемвекторы и временные реперные точки, а не скрин сервера каждую секунду или тик сервера. Я просто пока не пойму причины, почему реплей можно сделать, а это - нет. По сути же клиент в реплее частично эмулирует действия сервера. Надо просто в логике ядра сервера задать отдельные сиквенции для воспроизведения реплея, и для спектатора
Была идея сохранять пакеты от сервера к клиенту, ну что-бы типа не генерить их а просто проигрывать, пересылать клиенту. Нe моя идея, но кто как думает так и делает. Те же самые идеи про снапшоты, и гигабайты данных... Никто так не делает. Как вы думаете, как облачные технологии построенны, там логов выше крыши, не только тех которые можно видеть. Так вот, как такие сервисы как Splunk, Datadog или же что-то по проще работают? Просто отсылают кучу логов и засовывают их в специальные базы данных... Так что не только можно это все построить, технологии уже есть и железо очень быстрое стало. Ну это так, к слову о том что уже можно делать, а про что только мечтают.

Насчет проигрывания ивентов. Тут нужна система которая будет представлять из себя пошаговое воспроизведение пакетов из лога. Например монстр умер, а что до этого произошло? Были пакеты о NpcInfo , обновления по HP или дебаффов, ну и в конце пакет Die. Разберем более подробно:
- пакет NpcInfo выдается когда моб или npc входит в обзор игрового персонажа, на Яве это обычно проишодит в KnownList ( у Acis немного подругому, но смысл тот-же), нужен ивент что-бы сохранить данные моба. Что сохраняем? позицию, HP, номерок шаблона по данным о npc, ну и можно какие у него там бафы. Очень не много информации. Не надо весь пакет сохранять так как он будет намного больше (раз в десять)
- обновление по HP. Простой ивент про object id от моба, ну и новое значени по HP. Можно данные записать как и в NpcInfo описанные выше
- дебаффы. Типа пакета AbnormalStatusUpdate
- моб умерает, как пакет Die. Легче чем серверный пакет, координаты где умер, object id ну и можно добавить информацию можно спойлить или нет

Да, нужно собирать все ивенты от пакетов. Но сами пакеты от сервера будут передавать очень много информации, так как клиент может об все значенияx не знать. Так как у нас будет сервер, пакеты мы можеm сами генерить, но нам нужно сократить поток информации который мы будем либо сохранять в БД, либо проигрывать обратно из БД. По сути все что я описал (ивенты и как с ними работать) это и есть основа RPC . Просто надо немного привыкнуть к идее что не все данные нам нужны и что технологии уже есть и были, даже десять лет назад.
 
Зачем стер большой пост? Если человек действительно разбирается, он всегда может обьяснить человеку, даже новичку, простым языком))) и сам себя не жалеешь, стер свою работу(((
Да я не в том плане, что типа ты тупой и не поймешь, а в том, что я написал страницу текста и понял, что там еще две таких надо писать, чтобы закончить мысль. Короче если прям 3.14здец кратко - единственный способ это сделать в том виде в котором ты хочешь, это примерно то, что писал Gaikotsu, т.е буквально снапшоты сервера и ВСЕХ клиентов в реальном времени. В этом случае ты сможешь воспроизвести работу сервера БЛИЗКО к оригиналу, но все равно не полностью, т.к в сервере 80% активностей происходят по рандому, то тебе еще и генератор надо сохранять на каждое значение. Короче я не знаю как это можно в целом простым языком объяснить, когда контраргументы вот такие:
часто я делал то, что мне говорили невозможно спецы с десятилетиями опыта. Просто не стандартным путем.
 
Главный вопрос - чтобы что?
по поводу реализации хранения, есть облачные базы данных (amazon, ovh и тп), можно их разместить в одной подсети для более быстрого отклика, чтобы логгер чередовал сервера куда будет сохранять при записи и при этом запоминал этот порядок чтобы потом так-же воспроизвести. Можно даже выебнутся и когда заканчивается место - разворачивается еще один банк данных, подключается в общий порядок и так до бесконечности. Короче место это не проблема. Это конечно всё прикольно, но это уже из серии супер ненужных неокупаемых хотелок, которая нужна просто чтобы глаз радовала, имхо. Грамотная реализация такой фичи обойдется в кругленькую сумму. Представь себе поход на АК, 10 паков по 50-100 рыл. Все ТПшатся, бафаются, хуярятся, ресаются, тпшаются и так на протяжении нескольких часов, кого то выкинуло, кто то еще что-то, параллельно в DE Village кто то создал персонажа, короче оцените просто масштаб того что вам придется сохранять, это просто 3.14здец, но идея конечно прикольная.
 
Парни, я кажется плохо выразил мысль. Задача не полностью эмулировать все процессы ява-эмулятора (хыхы, масло масленое)), а сделать всего-лишь репродукцию результатов его работы. То есть такой медиа- плеер выдачи пакетов клиенту под заданные цели и с управлением.
Ща попытаюсь объяснить:
Подскажите плиз, что будет если:
1) поставить запись пакетов от сервера к клиенту, поиграть 5 минут. Далее запустить записанный поток пакетов насильно клиенту еще раз? как я понимаю - будет что-то типа реплея, только насильственного и как будто играют за тебя
2) можно вкратце на пальцах, как идет обмен пакетами между сервом и клиентом? как я понима- все что делается и отрисовывается, сначала одобряется сервером. То есть я нажал бежать - сервак получил пакет желания , далее выдал разрешение и характеристики процесса+ возможно промежуточные контрольные точки+ итд. После этого клиент побежал. То есть инфа от клиента - это пожелания, а от сервера - насильно исполняемые клиентом в меру его способностей)) Как я понимаю, на этом реплей и построен - клиенту в спец-моде просто кормится записанная линейка пакетов.
3) Что нам мешает повторить вышеописанное, только имея по сути скоординированные реплеи по всем игрокам? тогда можно будет переключаться между игроками, или наблюдать от третьего лица (в этом случае естественно мы будем видеть не все, что было на сервере, но только то и тогда, когда хоть кто-то из игроков был в этом месте и как-то взаимодействовал)
Была идея сохранять пакеты от сервера к клиенту, ну что-бы типа не генерить их а просто проигрывать, пересылать клиенту. Нe моя идея, но кто как думает так и делает. Те же самые идеи про снапшоты, и гигабайты данных... Никто так не делает. Как вы думаете, как облачные технологии построенны, там логов выше крыши, не только тех которые можно видеть. Так вот, как такие сервисы как Splunk, Datadog или же что-то по проще работают? Просто отсылают кучу логов и засовывают их в специальные базы данных... Так что не только можно это все построить, технологии уже есть и железо очень быстрое стало. Ну это так, к слову о том что уже можно делать, а про что только мечтают.

Насчет проигрывания ивентов. Тут нужна система которая будет представлять из себя пошаговое воспроизведение пакетов из лога. Например монстр умер, а что до этого произошло? Были пакеты о NpcInfo , обновления по HP или дебаффов, ну и в конце пакет Die. Разберем более подробно:
- пакет NpcInfo выдается когда моб или npc входит в обзор игрового персонажа, на Яве это обычно проишодит в KnownList ( у Acis немного подругому, но смысл тот-же), нужен ивент что-бы сохранить данные моба. Что сохраняем? позицию, HP, номерок шаблона по данным о npc, ну и можно какие у него там бафы. Очень не много информации. Не надо весь пакет сохранять так как он будет намного больше (раз в десять)
- обновление по HP. Простой ивент про object id от моба, ну и новое значени по HP. Можно данные записать как и в NpcInfo описанные выше
- дебаффы. Типа пакета AbnormalStatusUpdate
- моб умерает, как пакет Die. Легче чем серверный пакет, координаты где умер, object id ну и можно добавить информацию можно спойлить или нет

Да, нужно собирать все ивенты от пакетов. Но сами пакеты от сервера будут передавать очень много информации, так как клиент может об все значенияx не знать. Так как у нас будет сервер, пакеты мы можеm сами генерить, но нам нужно сократить поток информации который мы будем либо сохранять в БД, либо проигрывать обратно из БД. По сути все что я описал (ивенты и как с ними работать) это и есть основа RPC . Просто надо немного привыкнуть к идее что не все данные нам нужны и что технологии уже есть и были, даже десять лет назад.

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

Про ивенты не совсем понял. что такое ивент ?
Как мне это видится - в клиенте в игре ты тоже не знаешь, что ранее было с мобом, если с ним не взаимодействовал и не видел его респа. так что или пофиг на его раннюю историю, или она будет храниться в логе какого-то игрока, который ранее пинал этого моба допустим после его респа. если с мобом не было ни у каких игроков взаимодействия - таких даже можно не хранить - вычеркиваем для оптимизации. (надо сделать флаг в логах серва на факт взаимодействия).
По написанным тобою пакетам - это уже частная ситуация, допиливается в процессе. В остальном полностью согласен!



Да я не в том плане, что типа ты тупой и не поймешь, а в том, что я написал страницу текста и понял, что там еще две таких надо писать, чтобы закончить мысль. Короче если прям 3.14здец кратко - единственный способ это сделать в том виде в котором ты хочешь, это примерно то, что писал Gaikotsu, т.е буквально снапшоты сервера и ВСЕХ клиентов в реальном времени. В этом случае ты сможешь воспроизвести работу сервера БЛИЗКО к оригиналу, но все равно не полностью, т.к в сервере 80% активностей происходят по рандому, то тебе еще и генератор надо сохранять на каждое значение. Короче я не знаю как это можно в целом простым языком объяснить, когда контраргументы вот такие:

зря стер) я бы хоть первую часть ликбеза почитал) а то у меня весьма смутное представление о том, как работает и чем фарширована пакетка сервера.
Так как мне кажется, вы переусложнили то, что хочу сляпать я - поясню как могу. Смотри, есть же реплаи в клиенте, так? Клиент выдерживает кучу пакетов на АК и замесах - а ему еще надо отрисовывать все это и считать кучу геометрии и графики. Даже на древних компах. То есть это не космические технологии и не снапшоты ядра по тикам. Я в данном вариант хочу использовать мод сервера, когда он по сути является просто геометрической подложкой, без нпс, мобов, игроков и тд, чисто террейн. И при этом процесс в нем по нажатию кнопки "Плей" выдает записанную последовательность пакетов из реплея. Просто этот реплей будет более подробный и скоординированный+ не привязаный к игроку, с которого записан реплей, а за счет логики консолидации пакетов со всех игроков, записанных во время реальной работы сервера, даст возможность получать более подробный реплей, и как бы "выходя из тела одного игрока , который писал реплей". Допустим переключаясь между игроками, или вися на геоподложке в режиме спектатора, при взгляде со стороны.

Норм конртраргументы) Раз такой шаристый - должен понимать, какую мысль пытается родить чайник)


Главный вопрос - чтобы что?
по поводу реализации хранения, есть облачные базы данных (amazon, ovh и тп), можно их разместить в одной подсети для более быстрого отклика, чтобы логгер чередовал сервера куда будет сохранять при записи и при этом запоминал этот порядок чтобы потом так-же воспроизвести. Можно даже выебнутся и когда заканчивается место - разворачивается еще один банк данных, подключается в общий порядок и так до бесконечности. Короче место это не проблема. Это конечно всё прикольно, но это уже из серии супер ненужных неокупаемых хотелок, которая нужна просто чтобы глаз радовала, имхо. Грамотная реализация такой фичи обойдется в кругленькую сумму. Представь себе поход на АК, 10 паков по 50-100 рыл. Все ТПшатся, бафаются, хуярятся, ресаются, тпшаются и так на протяжении нескольких часов, кого то выкинуло, кто то еще что-то, параллельно в DE Village кто то создал персонажа, короче оцените просто масштаб того что вам придется сохранять, это просто 3.14здец, но идея конечно прикольная.

Выше уже писал) Чтобы:
1) делать более качественные тесты баланса, чтобы не количеством, а качеством проработки каждого боя работать
2)борьба с дюпами, багами, скамом. Сейчас разборка логов насколько мне известно - анальная боль админов. а так на возражение забаненого товарища ты просто кидаешь ему короткий реплей его косяков. при наличии логирования нетипичного прироста айтемов, которые может говорить о дюпе - ты очень быстро срисуешь его метод, посмотрев, какие операции выполнял человек. (не касается инжектов, хотя и там может чем поможет)
3) это просто АХYEННО) с этого можно было начать и закончить)

У меня сейчас логика ассоциативная - если уже есть подобные решения, пусть и более локальный (реплей. хотя нихyя себе, реплей мас-замеса тоже не кисло по логике такой), и сам клиент нормально тянет мас-замесы, а тем более сам сервер - то такое логирование вполне реалистичная задача не космических масштабов и технологий будущего. Если я не прав- с удовольствием послушаю, где именно :)

ЗЫ: спасибо что оценил идею :)))
 
Последнее редактирование:
Сейчас разборка логов насколько мне известно - анальная боль админов
если нет удобного интерфейса / прогера который тебе его напишет - наверно да, вообще обычно админ видит инцидент - приходит к своим технарям, дает им хорошеньких пиздюлей и смотрит за тем как инцидент решается) но если вы в соло админите серв, наверно да, каждый дюп это анальная боль :D
 
если нет удобного интерфейса / прогера который тебе его напишет - наверно да, вообще обычно админ видит инцидент - приходит к своим технарям, дает им хорошеньких пиздюлей и смотрит за тем как инцидент решается) но если вы в соло админите серв, наверно да, каждый дюп это анальная боль :D
Админ, который хотя бы на четверть не вникает в проблему, и не проверяет, что произошло, почему, и как кодеры решили проблему - это не админ, а сам по себе- анальная боль. или Маззь)
 
Админ, который хотя бы на четверть не вникает в проблему, и не проверяет, что произошло, почему, и как кодеры решили проблему - это не админ, а сам по себе- анальная боль. или Маззь)
Это уже больше задача тимлида в чьей зоне ответственности произошел инцидент, админу похуй как и что там произошло) главное чтобы решилось и не повторилось
 
Это уже больше задача тимлида в чьей зоне ответственности произошел инцидент, админу похуй как и что там произошло) главное чтобы решилось и не повторилось

Братюнь, ты точно про пиратки ЛА2?)) может там и ПМ, девопс есть, да? и всех по несколько) пару исключений не учитываем)
 
Если я правильно понял тебя, ты хочешь сделать что-то вроде расширенной записи и просмотра реплеев.
Я могу тебе несколько десятков проблем выписать, которые тебе придется решить. Главная сложность, не сохранить пакеты, а воспроизвести. Во-первых штатный клиент не имеет функционала под твои хотелки и писать это очень дорого, по ряду причин. Во-вторых, даже если ты идеально запишешь все пакеты которые корректно гипотетически может получить плеер, это не решит проблему, т.к БОЛЬШАЯ ЧАСТЬ входящих пакетов формируются ПЕРСОНАЛЬНО для КОНКРЕТНОГО получателя, учитывая кучу факторов, вроде релейшенов. Т.е ты не сможешь без костылей воспроизвести в клиенте, не предназначенные для него пакеты. В принципе на этом уже можно останавливаться, т.к это УЖЕ не решаемые задачи, в контексте адекватности. Если допустить, что ты все же нашел у себя 20-30к зелени на заказ кастомного клиента, который будет это все воспроизводить, то тебе предстоит еще овердохуя сопутствующих проблем, например с фильтрацией отправки пакетов по области видимости региона, в котором находится камера и еще много всего веселого. Поэтому я с темы офаюсь, т.к дальнейшее обсуждение уже не будет каким-то образом отличаться от флейма и будет лишь поводом набивать посты для участников. Все проблемы которые ты хочешь решить с помощью этого механизма - решаются с помощью обычных логов уже 20 лет существования ладвы и не требуют изобретения велосипеда.
 
Братюнь, ты точно про пиратки ЛА2?)) может там и ПМ, девопс есть, да? и всех по несколько) пару исключений не учитываем)
Я в целом про процесс разработки, а если мы говорим про домашние проекты под столом, то эта фича в принципе не родится на таком сервере без грамотной команды и нормального подхода к её решению
 
Если я правильно понял тебя, ты хочешь сделать что-то вроде расширенной записи и просмотра реплеев.
Я могу тебе несколько десятков проблем выписать, которые тебе придется решить. Главная сложность, не сохранить пакеты, а воспроизвести. Во-первых штатный клиент не имеет функционала под твои хотелки и писать это очень дорого, по ряду причин. Во-вторых, даже если ты идеально запишешь все пакеты которые корректно гипотетически может получить плеер, это не решит проблему, т.к БОЛЬШАЯ ЧАСТЬ входящих пакетов формируются ПЕРСОНАЛЬНО для КОНКРЕТНОГО получателя, учитывая кучу факторов, вроде релейшенов. Т.е ты не сможешь без костылей воспроизвести в клиенте, не предназначенные для него пакеты. В принципе на этом уже можно останавливаться, т.к это УЖЕ не решаемые задачи, в контексте адекватности. Если допустить, что ты все же нашел у себя 20-30к зелени на заказ кастомного клиента, который будет это все воспроизводить, то тебе предстоит еще овердохуя сопутствующих проблем, например с фильтрацией отправки пакетов по области видимости региона, в котором находится камера и еще много всего веселого. Поэтому я с темы офаюсь, т.к дальнейшее обсуждение уже не будет каким-то образом отличаться от флейма и будет лишь поводом набивать посты для участников. Все проблемы которые ты хочешь решить с помощью этого механизма - решаются с помощью обычных логов уже 20 лет существования ладвы и не требуют изобретения велосипеда.

Да, ты все верно понял :)
по пунктам:
1. согласен, вся фишка в логике сортировки и компановки/выборки пакетов для конкретного клиента. Я там задавал тебе вопросы, что произойдет, если ты насильно скормишь клиенту записанные ранее с него же пакеты. если воспроизведется то что ты ранее делал - то вот тебе и функционал, достаточно обычного клиента. а управление воспроизведением и смену перса/ локации камеры можешь делать через админ-окошко в клиенте. кастрированное серверное ядро то всеравно у тебя будет в онлайне, к которому ты приконектился, и которое тебе кормит эти связки сосисок, тьфу, пакетов.
2. что будет, если ты связку пакетов для персонального получателя скормишь другому, заменив идентификатор на правильный, что это якобы этому клиенту? (если я правильно выразился. как раз и хотел тебя спросить, как осуществляется персонализация пакетов, и как ее корректировать под другой клиент)
3. что такое релейшены в клиенте/сервере ЛА2?

4. про фильтрацию пакетов я уже говорил выше. да, нужен алгоритм, который будет при логировании пакетов подписывать их нужной инфой по области видимости и тд
5. не думай о том, зачем)) думай - как :)))

ЗЫ: мне бестолку набивать сообщения, все хайды по количеству сообщений мне и так видны. про это не переживай)



Я в целом про процесс разработки, а если мы говорим про домашние проекты под столом, то эта фича в принципе не родится на таком сервере без грамотной команды и нормального подхода к её решению

Ну почему, мне кажется в 2 рыла с грамотным прогером это вполне реально сваять за вполне вменяемый срок :)

у нерешаемых проблем обычно два решения))) 1 - не зажравшийся честный спец, с незашоренным мышлением. 2 - разобрать проблему по частям так, чтобы ее смог осилить обычный спец)
 
Последнее редактирование:
Обратите внимание, что данный пользователь заблокирован! Не совершайте с ним никаких сделок! Перейдите в его профиль, чтобы узнать причину блокировки.
Обложи логами интересующие тебя балансовые моменты и радуйся жизни, не травмируя психику читателей)
Делать что-то сложнее - не стоит свеч
Это называется, когда гуманитарий залетел в техническую тему и не понимает как должно быть на самом деле. По факту он наркоман глупый, пытается изобрести то, что до него изобрели 100500
 
  • Ха-ха-ха
Реакции: gpz
Назад
Сверху Снизу