обновление в блоге - Создание многопользовательского чата

[spirit-ua]

Сообщение от rzawm

Уважаемые, а как на сервере сделать так чтобы каждый из клинентов не мог слать сообщения чаще чем к примеру раз в 3 секунды. Понятно что надо использовать таймер, сделать какойто счётчик, но как? К примеру на форме разместить каойнибудь эдит для ввода интервала, и по нажатию на создать сервер, как бы применялся. Т.е. не давал никакому юзеру слать сообщения к примеру чаще чем через 3 секунды. Этим мы слегка сможем защитить сервер от падения, как сказать DDOS атак

1. Делаеш масив с пользователями(если есть регистрация на сервере) или же с номером канала.
2. При отправке сообщения клиентом ставиш в масиве метку с временем приема сообщения.
3. При повторном получении сообщения сервером проверяеш метку времени с учетом трех(или сколько тебе нада) секунд и в зависимости от результата отправляеш сообщение всем или конкретно клиенту о том что не прошло три секунды.
4. Обновляеш метку времени для клиента приславшего сообщение

[rzawm]

А что нибудь по ближе к коду можно? с каналами Массив с пользователями есть, из которого идёт отображение в UserListView

[Beermonza]

От DDos защищает таймер опроса каналов, ...с последними переделками можно ставить интервал ServerTimer 1000 мс или больше, и сообщения будут лежать в каналах, пока сервер не пройдется по ним и не обработает. Вы заведите на стороне клиента окошко с счетчиком от последнего вашего сообщения, ...так можно ориентироваться, когда можно отсылать следующее. Можно блокировать кнопку отправки пока не насчитает счетчик нужное количество времени. Это просто. Ставим TTimer, Interval в 1000 мс допустим, в теле таймера вывод в Edit переменной, переменная обрабатывается как Inc(t); ... т.е. тоже самое что t:=t+t. Как только t будет, например, 3, нужно разблокировать кнопку. Теперь в кнопке последними строками обнуляем t и блокируем саму кнопку. Получается, что после отправки кнопка станет недоступной, в окошке будут идти цифры, как только там будет 3, кнопка отправки снова станет доступной, цифры будут идти дальше, как только нажимается отправка, кнопка в блок, счетчик в 0, ...думаю все понятно.

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

[spirit-ua]

Сообщение от Beermonza

От DDos защищает таймер опроса каналов, ...с последними переделками можно ставить интервал ServerTimer 1000 мс или больше, и сообщения будут лежать в каналах, пока сервер не пройдется по ним и не обработает. Вы заведите на стороне клиента окошко с счетчиком от последнего вашего сообщения, ...так можно ориентироваться, когда можно отсылать следующее. Можно блокировать кнопку отправки пока не насчитает счетчик нужное количество времени. Это просто. Ставим TTimer, Interval в 1000 мс допустим, в теле таймера вывод в Edit переменной, переменная обрабатывается как Inc(t); ... т.е. тоже самое что t:=t+t. Как только t будет, например, 3, нужно разблокировать кнопку. Теперь в кнопке последними строками обнуляем t и блокируем саму кнопку. Получается, что после отправки кнопка станет недоступной, в окошке будут идти цифры, как только там будет 3, кнопка отправки снова станет доступной, цифры будут идти дальше, как только нажимается отправка, кнопка в блок, счетчик в 0, ...думаю все понятно.

Решение вкл.выкл. кнопки отправки сообщения со стороны клиента впринцепе неправильное потому как:
а) мне вдруг захотелось изменить интервал с 3х секунд на 2 и тогда что??? переписывать клиент и отправлять новую версию всем клиентам??? Можно решить это методом отсылки служ.сообщения с сервера в виде кол. секунд но это тоже неверное решение т.к. интервал будет для всех одинаков, а отсылать каждому клиенту сообщение с разным тайм-аутом это тоже, как мне кажется, неверное решение...
б) все манипуляции что касаемся управления сообщениями, настройками, флуд, мат и т.д. должно реализовываться со стороны сервера. От клиента должно зависить ровным счетем ничего, кроме отправки соосбщения(запроса), а уже сервер должен принемать решение "дать" или "послать"
Я, допустим, хочу реализовать викторину и мне очень кретично время приема соосбщения(ответы на вопросы) как тут быть??? а когда викторина закончена вкл. режим 1сек - 1 мессага. Также система которая следит за матом ну и т.д. - это я к тому что сервер ГЛАВНЫЙ.

Сообщение от Beermonza

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

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

[Beermonza]

spirit-ua, ну, что у вас за планы на программу я не в курсе, а вот скажу следующее. Если сервер читает каналы по-порядку через промежуток, то он защищен от лавинных запросов. Для чего нужно у клиента защитить кнопку отправки сообщений? ...это вторая защита, дополнительная, так сказать - "от дурака". По любому, если кто-то разгадает и будет слать сообщения чаще чем позволяет таймер клиента, все равно сообщения обрабатываться не будут, они будут затираться в каналах, и сервер в свою очередь опроса возьмет последнее сообщение. Т.е. мы клиенту ничего не передавали, и он не управляет сервером. Почему нужен статичный интервал блокировки? ...чтобы отсечь минимум времени, за которое возможно отправить какое-либо сообщение, ...и регулировать его не надо.

По поводу кодирования. Сканирующие программы не должны быть списаны на проблемы серверного приложения. Сервер должен быть защищен сам по себе, это его система, от него зависит, останутся ли "в живых" остальные пользователи чата, ...так что делайте выводы. На одном порту, одном и том же IP-адресе может быть до 30 000 каналов, и просмотреть можно любой из них, обнаружив активность. Если вам совершенно не важно будет программа работать долго или в нее забьют костыль, это ваши личные проблемы

[rzawm]

Но мне кажется, защиту от DOS атак надо реализовывать именно на сервер, т.е. чтобы он отказвался принимать с одного канала более одного сообщения скажем щаче чем в 3 секунды. На счёт шифрования, я полность поддерживаю Beermonzу, так как надёжность сервера повысится на много, ведь будут шифроваться как сами сообщения так и команыд. Для начала я предлогаю организовать шифрование с помощью сдвига кода символа на некоторое число к примеру 197, врезультате при прослушивании канала ничего путного понять нельзя будет (можно но гораздо сложнее)., т.е. при отправки сообщения все коды символов будут сдвигаться на 197, а при приёме обратно.

[Beermonza]

Так и есть, сейчас сервер не обрабатывает команды, пока не наступит время по таймеру, чем мы уже защитили сервер от лавинных запросов. Что касается вообще блокирования, чтобы протокол TCP/IP вообще не принимал никаких сообщений в некотором канале, то я пока не искал решение.
Что касается кодирования, ...если так посудить: "сдвиг кода символа на некоторое число к примеру 197", то мы уже выложили код на тарелочке ))) ...это элементарный и самый первый проверяемый алгоритм взлома информации. Есть иное предложение, ...использовать алгоритм упаковки, например тот же ZIP, по определенному ключу.

[rzawm]

А можно сделать наверное сдвиг не на конкретное число, а на какоето n- число, т.е. оно всегда разное будет, но в определённый момент времени для клиента и сервера будет являтся постоянным. Или использовать что то типа удостоверяющих сертификатов , например клиент при подключении к серверу получает определённой структуры файл зашифрованного вида, и только при наличии данного файла будет возможна работа клиента с сервером. Тем самым с сервером смогут работать только как сказать настоящие клинты, а ни какието левые программы и т.д.

[Beermonza]

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

[rzawm]

Так этот файл при каждой рассылке будет менятся, и для каждого пользователя он будет уникален. Т.е. клиент конектится получает файл, как сказть обрабатывает и отсылает серверу определённое сообщение, сервер сравнивает с отосланным, выполняеет определённые действия с отосланным и если отправленное сообщение как сказать совпадает, то клиент получает возможность общаться.

Не это что то мы кудато лишнего полезли, надо что то простое использовать. Всё таки это не банковская какая система, если уж на то пошло то почему бы и нет клиенту в комплект к клинтескому приложению не ставить ещё и CryptoPro CSP и каждое сообщение не подписывать ЭЦП. Шифрование обязательно нужно, но палку перегибать не стоит.