|
|
Практика работы с winsock в C++ Builder
В данной статье автор опишет только два чата, данная серия чатов LightChat...
Первый
был написан мной в целях саморазвития, в тот период я имел только
поверхностные знания, которые касались только написания программ для
сети. Зачастую для работы было необходимо связываться с партнером,
поэтому приходилось множество вопросов решать по телефону. А это было
очень долго.
Для тех, кто новичок в этом деле, лучше будет воспользоваться программированием
на C++ Builder, в котором имеются RAD-компоненты: ClientSocket и
ServerSocket, используемые для работы с сокетами. В настоящий момент
могу сказать, что данные компоненты лично мне не нравятся, потому что в
них есть недоработки, хотя в то время я этого не замечал.
При написании сервера на C++ Builder
сразу же необходимо решить вопрос, как сервер будет управлять
клиентами, потому что клиент должен иметь не только ник, но и IP адрес,
а также, статус и другие сведения. Далее необходимо решить вопрос о
формате пакетов. В моем случае пакет состоял из Имени отправителя, Типа
пакета, Имени принимающего, а также сами сообщения. Данные поля
разделялись между собой специальным символом, который должен был быть
не виден при печати. Поэтому пакет мог быть переменной длиной, в то
время это казалось положительным моментом.
Однако на самом
деле оказалось, что поля пакетов должны были извлекаться вручную:
сначала ник, тип и другие сведения, и только в конце было само
сообщение. Вторым отрицательным моментом, который напрямую связан с
первым, является свойство протокола TCP - соединять те пакеты, которые
ему кажутся маленькими, в один, по логике это повышает эффективность,
однако в данном случае, второй пакет терялся, так как был одной из
частей первого. Чтобы как-то исправить положение, мы ввели задержку
после отправки пакета, около 20 мс.
В то же время тип пакета
должен быть числом. Единственная замечательной возможностью в то время
было то, что можно было отправлять пакеты от пользователя с любым
именем, при этом не только сообщения, но и различные управляющие пакеты
тоже. Получалась забавная ситуация, можно было написать от имени одного
пользователя, а потом любого другого, разобраться в итоге кто есть кто
невозможно.
Следующие мои чаты стали более принципиальными, я
применял шифрование пакетов, не позволение отладки программ, а также
невозможность переполнения буфера. А из-за того, что чат был написан
руками, он работал стабильно, и сломать его было практически невозможно.
Все
пакеты сделаны были фиксированной длиной и типом, что позволило убрать
задержки, а также пропала необходимость выделять данные из принятой
строки. К тому же при формировании пакета, высчитывается некая
контрольная сумма, что позволило определить целостность пакета. В том
случае, если пакет не проходит тест на целостность или подлинность, то
он просто игнорируется.
Далее появилась возможность регистрации
ников, подобные данные хранятся на сервере в виде двух контрольных
сумм, которые являются четырехбайтовыми. При входе пользователя
происходит проверка ника, в случае нахождения контрольной суммы,
пользователя просят ввести пароль, при вводе неправильного пароля, либо
после 60-ти секунд простоя, его кикают. Дополнительно появилась
поддержка банов, таким образом, при входе проверяется IP пользователя,
и если он занесен в бан, то соединение прекращается. Еще можно оставить
сообщение для того пользователя, который отсутствует.
Большим
преимуществом было то, что на сервере постоянно имеется поток,
отслеживающий возможные атаки. Ими считается каждое соединение, которое
не изменяют ник с ника "по-умолчанию" - "default". Если данный поток
находит подобное подключение, то соединение закрывается.
|
| Категория: C# / C++ | Добавил: GL_Loney (19.09.2009)
|
| Просмотров: 2179
| Рейтинг: 1.0/1 |
|
| Статистика |
Онлайн всего: 1 Гостей: 1 Пользователей: 0 |
|
