вылеты модов во время игры

[nuo]

Не, ребят, я конечно все понимаю - кучу народу, которые любят взламывать ваш чит. Но хватит уже вешать лапшу на уши - сделайте нормальную проверку лицензий себе, поставьте таймбомбы и все. Не надо этой фигни с проверкой на сервере постоянной - ведь из за этого же моды вылетают, верно? Я просто тоже разработчик и уже видел недостатки такой системы защиты. Это не из за того, что провайдер теряет пакет - нет! это просто ваш сервер при большой нагрузке иногда сбрасывает ошибку - такую же, как при ддосе, только реже. Хотите использовать подобную защиту - НЕ пользуйтесь http протоколом. для этого подойдет постоянное tcp соединение - и нагрузки на ваш сервер не будет и взломать будет сложнее. сейчас взломать то, что вы там намутили - дело 1го дня. Я этого не делаю только потому, что меня устраивает стоимость вашей проги и постоянно крякать новую версию у меня нет желания - 10 баксов в месяц- копейки. Но если вы хотите, чтобы я и дальше оставался вашим довольным клиентом - исправляйте свои косяки, а не давайте левых обьяснений в надежде, что тут все технически безграмотные и не поймут что к чему. Если не зватает навыков на реализацию хорошей защиты - я так же с радостью вам подскажу что и как стоит сделать. И помните, взломать все равно можно что угодно - было бы желание, а уж вашу дополнительную проверку и подавно элементарно даже если вы запихнете ее очень много раз на протяжении всей проги - достаточно просто запустить свой сервис, который будет давать нужные ответы и внести 1 запись в файл hosts.

С Уважением, крайне недовольный пользователь.

[Sherman]

Не, ребят, я конечно все понимаю - кучу народу, которые любят взламывать ваш чит. Но хватит уже вешать лапшу на уши - сделайте нормальную проверку лицензий себе, поставьте таймбомбы и все. Не надо этой фигни с проверкой на сервере постоянной - ведь из за этого же моды вылетают, верно? Я просто тоже разработчик и уже видел недостатки такой системы защиты. Это не из за того, что провайдер теряет пакет - нет! это просто ваш сервер при большой нагрузке иногда сбрасывает ошибку - такую же, как при ддосе, только реже. Хотите использовать подобную защиту - НЕ пользуйтесь http протоколом. для этого подойдет постоянное tcp соединение - и нагрузки на ваш сервер не будет и взломать будет сложнее. сейчас взломать то, что вы там намутили - дело 1го дня. Я этого не делаю только потому, что меня устраивает стоимость вашей проги и постоянно крякать новую версию у меня нет желания - 10 баксов в месяц- копейки. Но если вы хотите, чтобы я и дальше оставался вашим довольным клиентом - исправляйте свои косяки, а не давайте левых обьяснений в надежде, что тут все технически безграмотные и не поймут что к чему. Если не зватает навыков на реализацию хорошей защиты - я так же с радостью вам подскажу что и как стоит сделать. И помните, взломать все равно можно что угодно - было бы желание, а уж вашу дополнительную проверку и подавно элементарно даже если вы запихнете ее очень много раз на протяжении всей проги - достаточно просто запустить свой сервис, который будет давать нужные ответы и внести 1 запись в файл hosts.

С Уважением, крайне недовольный пользователь.

Нам не "зватает" навыков на реализацию хорошей защиты, поэтому мы хотим от вас "обьяснений", как нам не использовать http, являющийся надстройкой над tcp. И с радостью попробовали бы ваш сервис, который будет давать нужные ответы, а мы уж поверьте внесем 1 запись в hosts.

А если серьезно, то на стороне сервера все достаточно хорошо защищено от DDoS. Проверка доступности сервера/проверка ключа делается раз в 2 минуты, достаточно редко, что бы загружать сервер при том количестве пользователей, которое есть сейчас. Таймаут на коннект на стороне клиента - 45 секунд. Если за 45 секунд клиент не соединился с сервером, и не получил несколько сотен байт, это в первую очередь проблемы с потерей пакетов. Если ответ не получен - та же "таймбомба" - моды выключаются. И не надо гнать на защиту проверки ключа, это именно то что вы предложили.

[nuo]

А вот представьте себе такую ситуацию - все ваши клиенты(ну или 90% из них) отправляют запрос одновременно. При таком раскладе http протокол, который, как вы верно заметили надстройка над tcp, даст сбой. Я не могу точно сказать где именно этот сбой происходит, так как не видел ваших скриптов, но варианта 2 - на серверной стороне при исполнении непосредственно скрипта - он не успевает дать ответ за 45 секунд или на стороне sql - достаточно отправить одновременно всего лишь 40-50 запросов к бд и некоторые из них будут обрабатываться секунд 20... а если эти запросы при этом еще и что то пишут в одну и ту же таблицу базы, то там совсем беда. Не использовать http - очень просто - сделайте постоянный tcp коннект. При постоянном коннекте не будет проблемы со сбоями в http протоколе. Ну а если проблема в sql, то тут вообще все просто - реал тайм серверы должны работать в 2 шага - на первом шаге есть кешированные данные( клиент зашел, данные загрузились в оперативку, вышел - выгрузились) и работа на первом шаге вопрос-ответ клиенту должна делаться на основе именно данных, висящих в оперативке, и уже на втором шаге - после ответа клиенту, данные синхронизируются с базой. В этом случае вы убираете нагрузку на базу и лишаете себя этих проблем.

[Sherman]

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

[nuo]

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

Вспомните пожалуйста, как работает http протокол? как работает вообще протокол tcp\ip? И чем tcp отличается от udp? По протоколу tcp НЕ БЫВАЕТ потерь данных - он будет отправлять эти данные столько сколько нужно пока клиент их не получит. Только в случае потери соединения с клиентом работа протокола будет прервана. именно поэтому - если происходит обмен данными по tcp протоколу(а http, как Вы правильно заметили, это верхний уровень tcp и принцип отправки данных там такой же). При этом http, хоть и является надстройкой над tcp при сбое не будет получать повторный запрос(только если вы сами сделаете это ручками в программе, что, как я понимаю, она у вас и делает, но только по расписанию, структуры try{}catch{} у вас там явно нет), а просто отправит ответ с кодом ошибки, что будет интерпретироваться вашей программой как неправильный и. соответственно, моды будут выключены. Если вы уверены, что проблема на стороне клиента и сервер тут не при чем - сделайте функционал как в браузерах, примерно такой - это оградит ваших клиентов от этой проблемы:

Код Выделить Развернуть


int i = 0;
bool success = false;
do {
try {
success = //подключаемся к сервису и обраюатываем запрос. тут скорее всего вебсервайс, если у вас все так, как я предполагаю, поэтому в одну строчку не получится, но, думаю, вы разберетесь
break;
}
carch(Exception ex)
{
//фильтруем коды ошибки
i++;
}
} while(i < 3);



синтаксис c# выбрал исходя из того, что ваша прога требует .net фреймворка.

[Sherman]

Warpack не требует .net, запрос на проверку ключа при ошибке отправляется еще 3 раза, как вы и показали в своем примере. Код отправки запроса заключен в обработчик исключений.

[nuo]

Ну из этого следует, то чоединение устанавливается, а следовательно надо смотреть в сторону сбоев в ответе с сервера или sql. Если Вы на время включите логирование на сервере всех пар хапрос-ответ к сервису, вы сможете сами убедится. Наврняка там будут периодически появлятся ответы с кодами 300, 500, 403 или 404. Это и будет моментом сбоя варпка.

[Sherman]

Ну из этого следует, то чоединение устанавливается, а следовательно надо смотреть в сторону сбоев в ответе с сервера или sql. Если Вы на время включите логирование на сервере всех пар хапрос-ответ к сервису, вы сможете сами убедится. Наврняка там будут периодически появлятся ответы с кодами 300, 500, 403 или 404. Это и будет моментом сбоя варпка.

Уверяю вас, логгирование ничего подобного не показало. Я вообще считаю эту беседу бессмысленной, потому что вы с чего то решили, что знаете намного больше нашего, и исходя из этого пытаетесь нас учить знаниям Капитана Очевидности. Весь диалог сводится к этому - вы пишите очевидность, я соглашаюсь.

[nuo]

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

[Sherman]

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

Если хотите что то дельное обсудить, пишите мне скайп, созвонимся, поболтаем.
ЗЫ. Прошу, когда получите нормально работающую прогу, вышлите вариант. Буду премного благодарен.

[DarkClone]

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

Вспомните пожалуйста, как работает http протокол? как работает вообще протокол tcp\ip? И чем tcp отличается от udp? По протоколу tcp НЕ БЫВАЕТ потерь данных - он будет отправлять эти данные столько сколько нужно пока клиент их не получит. Только в случае потери соединения с клиентом работа протокола будет прервана....

Улыбнуло. Напишите, пожалуйста, чуток подробней, тот самый момент который вы назвали "случаем потери соединения". И когда дойдете до потерь пакетов, не забудьте почитать что вам выше писал Шерман.

P.S. Я с удовольствием пообщаюсь на тему различия протоколов. Одна из моих профильных тем

[Dentist79]

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

[Sherman]

Дело в том что иногда мы делаем перезагрузку сервера. Не более одного раза в сутки, чаще один раз в несколько дней.
После ввода в ближайшее время второго сервера, подобная проблема будет устранена.

[Sherman]

Топик стартер решил ушел думать. Поэтому закрываю.