Коллективное написание многопоточного сервера на Qt

[bvn13]

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

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

[garryHotDog]

 судя по всему тема не пройдет......идея сдохла

[niXman]

почему сдохла?
что - кого не устроило?

[ieroglif]

ээх.. если б не нужда зарабатывать деньги - принял бы участие с большим удовольствием. =((

[garryHotDog]

так и не решили кто будет координатором!!!и активности ни какой

[ecspertiza]

Может реализовать, API на Qt много поточного сервера, затем на этом API реализовать демку клиент-серверное приложение, типа танчиков(денди), только могут подключаться куча народу(1000 человек) и устраивать батл По моему было бы забавно.

[Atan]

Привет всем, кто писал и следил над этой темой.
Я думаю, что её обсуждение напрасно остановлено и предлагаю всем желающим снова присоединиться.

Меня недавно тоже посетила идея написания сервера и клиента для сетевого общения на основе собственного протокола с шифрованием, естественно, на Qt. В зависимости от глубины проработки, формат общения будет укладываться от многоканального чата а-ля icq, или вырастет до полноценного форума.

Принципы системы:

Общение между клиентом и сервером происходит посредством коротких сообщений. Клиент отправляет комманду -> Сервер проверяет права клиента на её обработку -> Высылает клиенту ответ. Почти как в терминале *nix. Комманды к примеру такие: login, who, showprofile, showmsg, getfile. Для некоторых комманд предусматриваются аргументы, для других - ожидание дополнительного ввода от клиента.

Шифрование траффика. Судя по всему, эта тема хоть и поднята выше, но является достатночно тёмной для участников дискуссии (для меня тоже). Я сначала хотел для этой цели использовать QSslSocket, но быстро разочаровался в этом казалось бы беспроигрышном подходе, так как для этого нужно что-то скачивать, пересобирать Qt... (А что делать клиентам, которым тоже необходимо Ssl на компе как-то иметь!?) Благодаря вышеизложенным причинам крипт придётся делать свой. И я его (алгоритм) таки почти написал. Но пока не проработал механизм аутентификации, передачи сертификатов/ключей, имею высказать следующую мысль: в ходе сеанса связи клиент и сервер обмениваются зашифрованными посланиями, в которых содержится само сообщение + ключ, которым должно быть зашифровано следующее послание от "собеседника". Насколько могу судить, единственная возможность расшифровки для третьей стороны - это просечь момент, когда "собеседники" только-только обменялись ключами, в начале сеанса. Иначе - успеть забрутфорсить и разгадать ключ, пока он не поменялся снова. Вероятность этого - 0,00001%. Схема настолько проста, что мне прям не верится, неужели всё так гладко?

Многопоточность. Это в общем-то та вещь, с которой у меня не получается разобраться своими силами. Ещё больше раздосадовало то, что доступ к БД с помощью QSqlQuery возможен только из потока, в котором соединение с базкой и было установленно. Цитирую из QtHelp: "A connection can only be used from within the thread that created it. Moving connections between threads or creating queries from a different thread is not supported."

От идеи p2p я отказался по причине дополнительной сложности её тестирования и реализации. Это мне пока не по силам. Но, с другой стороны, p2p можно включить и позднее, благо будущий протокол этого не запрещает. Её сущность возможно будет заключаться в том, что зарегистрированный пользователь при желании будет брать на себя часть информации, которую хранит сервер, и при случае отправлять её нуждающимся в ней клиентам по команде сервера.

Дабы как-то разжечь дискуссию и не быть голословным, прикрепляю к сообщению архив с исходниками сервера и простейшего клиента командной строки. Сервер уже умеет коннектиться к БД, загружать оттуда настройки, производить идентификацию клиента по логину-паролю и проверку прав доступа. Реализован простенький чат. Как было сказано выше, работает в однопоточном режиме. Параметры коннекта к БД (адрес, тип, логин-пароль) прописываются в файлике bd.ini. С согласия знакомого владельца сервака с MySQL я могу дать параметры коннекта к его базе.

P.S. я конечно осознаю, что разработка данной системы на Qt, как и сама система, не слишком рентабельное дело в смысле его "велосипедности". Не покидает вопрос о том, зачем это писать, если есть web-сервера со своей многопоточностью, PHP со своей универсальностью, если есть Jabber, в конце концов... У меня рационального ответа не нашлось (просто привлекательна сама мысль о написании клиент-сервера на Qt). Поэтому, пока не надоело самому, прошу поддержать и посодействовать всех единомышленников-добровольцев.

[niXman]

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

но я хз как на Qt можно что-то подобное написать...ИМХО.

[ieroglif]

Лично мне необходим клиент-серверный каркас, на основе которого можно было бы делать игровые проекты.
Разумеется, под Qt
На данный момент есть в сети проект кроссплатформенного GNE (Game Network Engine) - думаю что было бы очень приятно переписать его под Qt Либо - это хороший толчок

[JamS007]

Я бы с удовольствием присоеднился, но, чувствую, толку с меня мало будет... Наоборот, хотелось бы чему-то научиться, поработать в команде, набраться опыту.

[Igors]

Много раз использовал multi-threading для относительно небольших задач и мнил что понимаю этот аспект/вопрос  Однако первый же серьезный запрос заказчика сделать существующее application multi-threaded показал что на деле я понимаю очень немного  Напр прямолинейное использование mutex'ов будет в минус (а не в плюс). Масса проблем возникает на уровне что и как распараллелить и.т.п

Присоединиться я не смогу, но дело хорошее, welcome

[merke]

Вот выкладываю пример клиент-серверного приложения (сервер многопоточный). Исходник найден на одном форуме. Думаю, данный исходник даст толчок к началу обсуждений.

http://turbobit.net/awvsvkcznij0.html

[labview]

Привет!

Я удачно сделал такой проект под названием Чат на другом языке программирования. Сервер был устроен так:

Два параллельных потока. Один поток рассыльщик, второй постоянно ждёт открытия соединения. Как только клиент пытается открыть соединение, сервер открывает отдельный поток. То есть каждый клиент имеет свой поток.
Клиентский поток считывает данные через TCP/IP и отсылает эти данные через очередь рассыльщику, который отправляет сообщение всем имеющимся клиентским потокам, которые в свою очередь отправляют сообщение через TCP/IP всем клиентам.

Система работает, серверная программа заинсталлирована на веб-сервере, протокол открыт. Если есть интерес я могу попробовать переписать всё на Qt. Если кто то хочет попробовать написать клиента для рабочего сервера, могу описать используемый протокол (он очень простой). Если кому то нужны подробные пояснения к организации сервера или клиента, могу описать.

Прилагаю ссылку на скрин клиента и исходники кода на языке LabVIEW:
http://labviewportal.eu/ru/internet-tehnologii/154-2009-07-25-16-53-48

Ссылка на бурное обсуждение этого проекта (там есть много пояснений):
http://labviewportal.eu/viewtopic.php?f=142&t=853

С уважением!