Сервер с БД на QT?

Question

[Kirill H]

Краткое содержание

Начал знакомится с таким IDE как Qt, много чего интересного тут мне приглянулось, вот уже работаю больше месяца. Слышал такое выражение, что каждый уважающий себя программист должен хоть раз в жизни написать свой текстовый чат. Разобрался и накалякал на коленке на основе QTcp простенькую библиотечку чтобы передавать файлы и просто текстовые строки через Tcp сокет. Всё что необходимо, это знать IP получателя. Решил апнуть чатики, дописав туда сервер, что будет держать в себе список соответствия ников и ip с которого последний раз заходил конкретный пользователь пользователь. Ну и перед тем как приступить к разработке SRS и архитектуре, решил иследовать вопрос на чем как лучше организовать сервер, раньше с сетью не работал.

Теги что меня интересуют:

1. Как организовать соединение с сервером (знаю, может это и извращение, но сервер хочется сделать тоже на Qt), возможно переход с tcp на какую-то другую технологию, ведь пока что, для связи сервера с каждым пользователем придется выделять ресурсы на отдельный инстанс сокета, а это что-то как-то не камельфо.
   
2. Как обрабатывать БД, использовать стороннюю систему управления БД, на подобии MySQL или какая-то гибридная связь с Qt, либо пользовать штатные средства Qt (правда я так понимаю, что они имеют только косвенную связь с нормальными СУБД).
   

Важно
Это просто home-made project, ничего особого тут нет и более того, это чудо максимум появится на GitHub, просто продолжаю знакомится с интересным IDE и по вечерам играюсь с интересной темой.

Спасибо за ваши осоветы! Мне мне интересно мнение людей, что уже знакомы с Qt и которые могут просветить меня в этом темном лесе сетей :)

Comments

[devalone]

Начал знакомится с таким IDE как Qt

Qt - это фреймворк, а не IDE

[devalone]

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

Нет не должен

Answer 1

[Ighor July]

1. TCP не особо и плох. Сомневаюсь что у вас будет больше 1000 сокетов одновременных.
2. Можно использовать SQLite файл, и напрямую проганять через него клиентские команды, а можно и на QHash организовать подобие базы, а на Qt Script принимать запросы. Первый вариант проще.

Comments

[Kirill H]

Да, я тоже так примерно представляю, понимаю что онлайн в чате будет только я) Но хочется практически дать возможность обрабатывать одовременный доступ больше 1000 пользователей. И держать БД в ОЗУ мне кажется не самой лучшей затеей. По этому и полез к СУБД.

[Ighor July]

Держать БД в ОЗУ нормальная затея. Я в QHash хранил больше 5 млн записей и все работало быстро.
Но если вы будете делать индексацию, то объем памяти будет умножен на их количество.
Если памяти хватает то хранить БД там лучший вариант, и в отдельном потоке сохранять все изменения в файлы или другие БД в пассивном режиме.

[Kirill H]

Игорь Джулай: Да, вы правы, вроде как не особо много выходит если вникнуть в цифорки

[Kirill H]

Игорь Джулай: Тогда один вопрос снят, окей, держим всю БД в ОЗУ.
Но что до запросов пользователей. Допустим на сервере будем хранить только nic, passwordHash, lastIp. сообщения будут идти напрямую from client1 to client2. То есть сервер нужен только чтобы залогинится и узнать ip c которого заходит конкретный user что бы узнать на какой ip отправлять данные. Это снижает все запросы к серверу только к запросам:

1. Авторизации
   
2. getIp конкретного user-а
   

Но всё же на каждого клиента придется инстанциировать по одному объекту QTcpSoket-а, на время подключения и передачи данных. Можно этого как-то избежать, есть идеи?

[Ighor July]

Kirill H: можно по UDP передавать, но придется компенсировать потерю пакета и учитывать пропускную способность клиента. Проще с TCP работать, портов на ІР доступно 65 тыс.
И да, там Qt SQLite драйвер умеет базу в памяти хранить, чуть медленнее но если вам нужны SQL запросы то такой вариант сойдет.

[Kirill H]

Игорь Джулай: Думаю обойдусь вашим решением, c QHash, спасибо большое вам :)

Answer 2

[Армянское Радио]

В Qt есть огромное количество штатных средств для работы со всеми популярными СУБД. И даже Firebird есть.

QSqlDatabase

Comments

[Kirill H]

Уточню вопрос, мне интересно с точки зрения производительности, стоит ли поднимать паралельно с сервером СУБД, что бы снять нагрузку с процесса сервера, таким образом что бы приложение сервера просто общалось с СУБД запросами.