Сервер преставляет из себя консольную программу под win32, котрая прослушивает два порта. сама форма сервера не является особо важной, потому что переделать его ввиде сервиса и ГУИ интерфейсом или в программу под UNIX - дело нескольких минут. Один из портов используется если вы не хотите использовать ssl протокол. Тогда пакеты передаются просто открытым текстом, что в прочем никак не нарушет безопастности. Второй прослушивается для входящих ssl коннектов.
Время которое тикает на сервере служит двум целям. Во первых оно просто и красиво показывает момент в который произошло то или иное событие. Во вторых время это играет роль системного пульса. Попросту говорит о том что сервер не завис.
Самое важное место INI файле сервера занимают четыре секции секции: [pass] [admin] [options] [disable].
| [options] | настройки сервера |
| [pass] | юзеры и их пароли (33=test UIN:33 password:test) |
| [admin] | права юзеров (ненулевое значение обозначает возможность админского доступа) |
| [disable] | запреты юзеров (ненулевое значение обозначает то что юзер заблокирован и входить не может) |
Касательно пейджера. в настройкх пейджера можно указать адрес и порт сервера на который надо заходить. Порт можно не указывать, тогда он просто будет установлен по умолчанию, 34 или 33 в зависимости от того включён ssl коннект или нет. Если вы хотите запустить два пейжера на одном компе, то разнесите их по разным каталогам, иначе конфиги у них будут немного в конфликте.
1) хранение настроек в ini файлах. во первых их нужно шифровать или шифровать по крайней мере сами пароли, т.е. хранить чисто для приличия хеш от пароля. А во время авторизации использовать не хешировать пароль, а хешировать хеш от пароля. Кроме того для сервера ini файл просто не приемлем в плане скорости и объёма. Так же трудно делать с ним регистрацию и многие другие вещи (процеес вычисления свободного UIN-а не тривиален). Очень неплохо бы подошёл для этих целей sqlite. Хотя правда его профессиональная версия с шифрованием стоит штуку зелёных. Можно на худой конец сделать в рукопашную какое-то своё хранилище.
2) вектора. Все жизненно важные текущие данные хранятся ввиде векторов. Коннекты, чаты и т.д. И хотя способы с ними работы при возрастании количества данных тормозят работу не сильно (ибо построенны эффективно). Тормоза создаёт сам процесс доступа, поиск нужного значения, поиск свободно места - по своей природе абсолютно линейны. Хотя если сервер расчитывать сервер клиентов этак на сто, то проблем никаких. А если будет очень много людей, то серверу сильно поплохеет. Если два выхода. Во первых можно оставить все вектора наместе, и просто ускорить один только доступ. Прикрепить бинарное дерево для поиска и битовую маску (которая ускорит поиск свободных элементов раза этак в 32). Вектора имеют разный тип элементов, но выше означенные структуры для каждого из них будут одни и теже, что довольно таки хорошо.
Вариант второй. Очень неплохо в роли хранилища подобных данных внутри сервера - будут смотреться b-деревья. Во первых поиск, удаление и вставка будет происходить быстро. Свободное место искать не надо. И самое приятное что стурктуры будут опять же универсальны для всех типов данных, а экономия и скорость выделения памяти ещё выше. Потому как дерево можно сделать само по себе, а данные сами по себе. Просто прикрепить к каждому узлу небольшой вектор, из однотипных пользовательских даных.
3) Чаты. Мелкая поправка. Очень не рекомендую применять чаты с шифром RC4. Я бы его просто вычеркнул из меню, но не охота перепаковывать исходник.
Вообще постараюсь объяснить одну из деталей. RC4 потоковый шифр, в котором текст шифруется в помошью XOR. Ключ во время сеанса постоянен. Поэтому если взять две разные строки и наложить друг на друга - получатся две нешифрованные строки, которые наложены. А их несмотря на любые ухищрения, можно расшифровать (это умели делать даже в те времена, когда блочных шифров не существовало).
Итак клиент посылающий первое сообщение должен запросить публичный ключ у сервера. И если надо подпись ключа у клиента
которому передаётся сообщение. В дальнейшем публичный ключ запонимается и сообщения шлются сразу.
Если клиент покидает сервер, то клиенты знающие его публиный ключ, ключ этот забывают.
Если клиент хочет пригласить других клиентов в чат, то он должен запросить его публичный ключ и если надо проверить подпись ключа.
Этот процесс аналогичен отсылке обычного сообщения, т.е. используется тот же самый публичный ключ.
Вместе с приглашением клиент отсылает пароль для шифрования сообщений в чате (пароль зашифрован публичным ключём).
Исполяемые файлы + DLL и сертификаты
