Сообщения

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

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

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

Вспомните пожалуйста, как работает 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 фреймворка.

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

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

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

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