Я с телефона. На андройде есть "болезнь", автозамена слов. Как раз оно и сработало.
На счёт второго: Ну есть поток 1, есть поток 2, нельзя предугадать какой выполнится первым
Я с телефона. На андройде есть "болезнь", автозамена слов. Как раз оно и сработало.
На счёт второго: Ну есть поток 1, есть поток 2, нельзя предугадать какой выполнится первым
Последний раз редактировалось $continue$; 28.03.2018 в 23:06.
Это не работает на запросах, связанных с аккаунтами игроков. Как я уже сказал, каждый результат запроса "привязан" к ID игрока (именно для того ты и передаёшь "playerid" в mysql_tuery). Точнее, передавая ID, мы понимаем для какого игрока какой результат обрабатывать.
Единственная уязвимость в этом случае - если один игрок отправит запрос на загрузку данных и выйдет с сервера, а другой игрок в этот момент зайдёт на слот первого игрока и результат запроса придёт только к этому моменту. Собственно, получится, что данные одного игрока сработали на другом и то условие, что показал автор, как раз защищает от этого.
Защита происходит за счёт того, что мы контролируем количество срабатываний OnPlayerConnect для каждого ID игрока, прибавляя каждый раз единицу к переменной и передавая это значение в наш паблик для обработки запроса, указывая его вместе с playerid в mysql_tquery. Далее, когда запрос сработал, мы проверяем, равны ли текущее значение переменной и то значение, что мы передали. Если нет, значит под тот ID игрока, который отправил запрос, во время обработки запроса успел зайти другой игрок.
То бишь:
- Игрок зашёл на сервер, сработал OnPlayerConnect и к переменной прибавилась единица (сейчас значение равно "1")
- Запрос отправился, а в паблик, созданный для обработки запроса, был передан ID игрока и значение переменной (1)
- Далее игрок выходит с сервера, не додидаясь результата запроса
- Заходит другой игрок под тот же ID и значение переменной уже становится равным "2"
- Запрос, который отправил первый игрок, наконец, обрабатывается и переданное значение сравнивается с текущим значением переменной (в данном случае у тас будет "1" и "2")
- ...
- PROFIT!!!
Вот так мы и поймём, что запрос отправлял не тот игрок
Но такое возможно только в случае, если запрос будет обрабатываться достаточно долго, о чём даже в комментарии написано:
Собственно, в этом комментарии как раз и описан принцип работы сей уязвимостиplayer A connects -> SELECT query is fired -> this query takes very long
while the query is still processing, player A with playerid 2 disconnects
player B joins now with playerid 2 -> our laggy SELECT query is finally finished, but for the wrong player
what do we do against it?
we create a connection count for each playerid and increase it everytime the playerid connects or disconnects
we also pass the current value of the connection count to our OnPlayerDataLoaded callback
then we check if current connection count is the same as connection count we passed to the callback
if yes, everything is okay, if not, we just kick the player
UPD: Вангую в ответ что-то типа: "Я и так всё это знал. Зачем ты мне это расписывал". Я описывал это не только для тебя, а для автора и всех остальных, кому интересно как это работает.
Последний раз редактировалось DeimoS; 28.03.2018 в 14:13.
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Elrmrnt-Kritik (28.03.2018)
Так, гонка потоков не только в плагине. Я объяснил, что есть такая ситуация и зачем BlueG сделал переменную.
Я же не говорил, обязательно использую доп.переменную. К слову, я сам не использую в запросах :)
Последний раз редактировалось $continue$; 28.03.2018 в 14:58.
Value your freedom or you will lose it, teaches history. "Don't bother us with politics," respond those who don't want to learn. (c) Richard Stallman
Эмм, а кто сказал, что гонка потоков есть только в плагине?
Речь о том, что принцип появления ошибки нельзя описать как:
ибо дело тут не в том, какой из потоков сработает первым, а в том, что в первом потоке имеется важное условие для обработки результата второго потока, которым является игрок. И когда второй поток завершит свою работу, нужно удостовериться, что его данные для первого потока ещё актуальны.Ну есть поток 1, есть поток 2, нельзя предугадать какой выполнится первый.
И это всё ещё является уязвимостью ;)
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Спасибо большое за очередную отзывчивость и помощь. В этом вопросе в принципе разобрался. Лишней не будет эта штука, добавлю. Хотя и вправду, навряд ли так быстро игроки могут успеть зайти.
Правда не понял из-за чего у вас сыр-бор, в драку влезать не буду
Я же написал причину выше, ну -_-
Окей. Обратимся к википедии:
В нашем случае мы просто контролируем актуальность данных, а не зависим от порядка выполнения.Состояние гонки (англ. race condition), также конкуренция — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода.
Эмм, а это к чему?
Я, например, не люблю писать с ошибками и если делаю какие-то ошибки, которые впоследствии замечаю сам или подмечают другие, стараюсь от них избавляться. Все мы не без греха
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
Value your freedom or you will lose it, teaches history. "Don't bother us with politics," respond those who don't want to learn. (c) Richard Stallman
И правда, лол.
Пойми же ты, гонку потоков определяет не только следствие, но и причина. Обычно под гонкой потоков принято называть случаи, когда несколько работают одновременно с одной и той же информацией, при этом, хотя бы один из потоков должен эту информацию обновлять, из-за чего все остальные потоки, в лучшем случае, будут получать уже устаревшие данные. И чем больше потоков делает перезапись, тем больше коллизий данных происходит. То, что в нашем случае в определении ситуации присутствует слово "потоки", не делает всю ситуацию равноценной гонкам потоков.
Давай попробуем пойти от обратного и, опять же, обратится к сторонним источникам.
Википедия:
studexpo.ruСостояние гонки (англ. race condition), также конкуренция — ошибка проектирования многопоточной системы или приложения, при которой работа системы или приложения зависит от того, в каком порядке выполняются части кода.
www.viva64.comОдной из основных ошибок в многопоточных программах является так называемое состояние гонки (race condition). Это случается, если программист считает, что один поток закончит выполнение своих действий, например, подготовку каких-либо данных, до того, как эти данные потребуются другому потоку.
support.microsoft.comСостояние гонки возникает тогда, когда несколько потоков многопоточного приложения пытаются одновременно получить доступ к данным, причем хотя бы один поток выполняет запись.
Состояние гонки возникает, когда два потока доступа к общей переменной в то же время. Оба потока считывают одно и тоже значение переменной. Оба потока производят какие-либо действия со значением и далее возникает гонка за то, кто последним сможет записать новое значение. Поток, который запишет значение последним перезапишет значение, которое записал предыдущий поток.
Видишь? Везде говорится о том, что гонка потоков возникает, когда НЕСКОЛЬКО ПОТОКОВ ОДНОВРЕМЕННО РАБОТАЮТ С ОБЩИМИ ДАННЫМИ. В этом главная суть гонки потоков. Имеется несколько независимых потоков, которые могут влиять на какие-то одни данные, что и приводит к проблемам.
В нашем случае мы имеем главный поток и второстепенный. При том, второстепенный никак не влияет на данные главного, а лишь является связующим звеном между базой данных и этим основным потоком, передавая информацию. И эта информация может потерять актуальность, так как во время обработки этой информации игрок вышел с сервера. И нет никакой гонки потоков. Есть просто более актуальные данные и менее актуальные. Проблема именно в этом, а не в том, что у нас есть несколько потоков, которые не синхронизируются между собой.
Гонка потоков будет, если мы, например, создадим отдельный поток и начнём проверять в нём, находится ли игрок в определённой зоне на карте и если находится - будем присваивать общей переменной единицу. Во втором же потоке будем проверять значение этой переменной. И вот тут уже может случится ситуация, когда игрок вошёл в нужную зону и мы начали проверять переменную во втором потоке, но первый поток ещё не успел обновить данные переменной, из-за чего второй поток скажет, что игрок не в зоне. Вот это и будет типичной гонкой потоков. Тут есть 2 потока, которые зависят друг от друга. В нашем случае нет никакой зависимости. Есть лишь актуальность для данных, которая может истечь не потому что один поток обработался быстрее другого, а потому что сменился получатель.
Хотя я, кажется, понимаю в чём именно заключается причина твоего заблуждения. Ты говоришь именно о потоках, в которых отправляются запросы, да? Мол считаешь, что может случится ситуация, при которой поток от вышедшего игрока будет обрабатываться медленнее, чем от только зашедшего? Только в этой ситуации я вижу хоть какое-то подобие гонки потоков (хотя, опять же, это не она, ибо отсутствует главный показатель: влияние одного потока на те данные, с которыми работает другой поток). Но такое просто физически невозможно, ибо если БД долго обрабатывает запрос одного пользователя, то логично, что проблема именно в запросе/таблице и все последующие запросы будут обрабатываться так же долго.
Хотя если даже представить, что такая ситуация возможна, то игрока всё равно кикнет, когда первый запрос всё же обработается, ибо проверка всё равно сработает. Так что я не совсем понимаю какой логикой ты руководствуешься
Последний раз редактировалось DeimoS; 29.03.2018 в 09:20.
Связаться со мной в VK можно через личные сообщения этой группы
Заказы не принимаю
Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
Великих идей полно, на них нет спроса.
Воплощение идеи в законченную игру требует долгой работы,
таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
Предложить идею просто, воплотить – вот в чём проблема
Steve Pavlina
* Многобукаф *
И все равно , до чего ты докапался и пытаешься другими, более развернутыми словами, что-то доказать?
Ты писал thread приложения?
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)