|
|
Регистрация Восстановить пароль |
Регистрация | Задать вопрос |
Заплачу за решение |
Новые сообщения |
Сообщения за день |
Расширенный поиск |
Правила |
Всё прочитано |
|
|
Опции темы | Поиск в этой теме |
22.10.2013, 13:29 | #11 | ||
Белик Виталий :)
Старожил
Регистрация: 23.07.2007
Сообщений: 57,097
|
Цитата:
Цитата:
I'm learning to live...
|
||
22.10.2013, 14:00 | #12 | |
Подтвердите свой е-майл
Регистрация: 29.08.2012
Сообщений: 4,011
|
Цитата:
|
|
22.10.2013, 14:01 | #13 | |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Цитата:
- Предположим в сети два юзверя, общаются в чате, оба получают данные из БД MySQL. Один написал "Здарова чувак!", база данных обновилась, но второй юзверь об этом не знает. Предлагать ему обновляться после каждой мессаги, ну как то тупо будет, особенно если в чате 50 юзверей... Тут нужна какая то своя система итераций, либо читать из БД через определенный интервал только информация которой возможны изменения по функционалу программы, либо иметь на сервере (или в той же БД) какой то флаг, ответ в виде: - Опачки, а база данных то обновилась и в ней есть новые записи, бегом читать новые мессаги. |
|
22.10.2013, 14:22 | #14 | |
Пользователь
Регистрация: 26.12.2009
Сообщений: 95
|
Цитата:
да да именно это, в том числе обновление даных в гридах. В принципе и штатно реализовано хорошо, достаточно только пере открыть форму и уже все обновлено, но хочется именно про мессаги примерчик. |
|
22.10.2013, 14:45 | #15 |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Вообще для таких приложений, где идут диалоги между одним сервером MySQL и толпой клиентов, ИМХО нужно писать свой сервер который и будет вести эти диалоги. Но это не MySQL сервер, это как раз промежуточное звено для связи "общественности с президентом".
На мой взгляд не очень хорошая ситуация, когда к одному серверу MySQL одновременно подключены сотни клиентов. Неизвестно чего они могут там нагородить и хуже всего то что сами между собой запутаются. Каково например предположить ситуацию (почти не реальную) когда два или три юзверя, попытаются сделать запись в БД практически в один момент времемени? Примером такого сервера может служить PHP, это для Web. То есть PHP сервер сам (один) подключается к БД и сам делает там все изменения, а всех клиентов об этом даже не уведомляет, потому что в Web в этом нет необходимости. Клиенты получают обновленную инфу по мере обновления страниц. В случае с работой MySQL в качестве какого то другого сервиса, для этого сервиса и нужно писать свой сервер, но только не MySQL (прошу не путать), а именно для связи с MySQL. Кладовщик на овощной базе - это и есть сервер самой овощной базы, думаю так понятней. Клиент просто приходит и говорит: - Дайте мне помидор. А Кладовщик отвечает: - Помидоры закончились, обратитесь завтра... Так вот видимо вам и нужно писать сервер "кладовщик". PS Но опять таки это мое ИМХО, я бы поступил именно так. Последний раз редактировалось Vladiger; 22.10.2013 в 14:51. |
22.10.2013, 15:21 | #16 | |
Пользователь
Регистрация: 26.12.2009
Сообщений: 95
|
Цитата:
не насчет одновременного добавления записей это нормально, такие базы для этого и созданы, транзакция или проходит целиком или не проходит совсем.Этот сайт работает с mysql, причем напрямую, мы же можем одновременно написать сообщения, тем более если на сайте пару тысяч человек, то так зачастую и происходит. правда, обновлять надо руками... А насчет сервера- посредника клиента и базы это впринципе и был вопрос изначально, хотелось бы какие-нибудь примеры,не совсем понятно что именно делает сервер к примеру если юзер нажал добавить запись, то он обращается к серверу и тот добавляет, но это посути тоже самое что сразу обратиться к мускулу. Гденибудь есть исходники более приличной сетевой программы, чем пример чата с сокетами. А именно использование гридов и человек 20 онлайн юзеров Последний раз редактировалось undead92; 22.10.2013 в 15:29. |
|
22.10.2013, 15:45 | #17 | ||
Подтвердите свой е-майл
Регистрация: 29.08.2012
Сообщений: 4,011
|
Цитата:
Цитата:
Последний раз редактировалось Stilet; 22.10.2013 в 16:32. |
||
22.10.2013, 16:01 | #18 | |
Пользователь
Регистрация: 31.08.2013
Сообщений: 93
|
Цитата:
Все 20 юзверей в онлайн могут подключиться к мускулю и в случае с вашим вопросом относительно обновлений таблиц на примере тех же сообщений в чате им придется долбить эту базу своими итерациями, делая постоянные запросы в нее и получая одни и те же ответы практически непрерывно, до того момента пока какая нибудь из таблиц действительно не обновится. Ладно ещё 20 юзверей, а если 200? Да они просто напросто повесят и опрокинут сервер MySQL, смотря конечно как часто они будут делать запросы в БД. И чем короче периоды этих итераций, тем лучше для клиента, т.к. он становится ближе к реал-тайм, но тем же хуже для сервера MySQL, потому как ему всё это дело разгребать... А вот если бы было промежуточное звено, то ситуация с обращениями в БД могла бы выглядеть примерно так: Клиент серверу: - HELO Сервер устанавливает соединение, выделяет канал и ресурсы новому клиенту, отвечает: - OK Клиент серверу: - GET MESSAGES На основании того, что клиент только что подключился, делает запрос в БД и посылает клиенту сообщения из БД, при этом ждет от клиента уведомление о получении. Клиент серверу: MESSAGE RECEIVED OK Сервер уведомлен что данный клиент получил все сообщения и у себя в памяти устанавливает этому клиенту булевый флаг TRUE (сообщения доставленны) Далее начинаются непрерывные итерации клиент <-> сервер до тех пор пока кто нибудь не напишет новое сообщение и сервер не пометит у себя что в БД появились обновления: Клиент серверу: GET MESSAGES Сервер клиенту: EMPTY Клиент серверу: GET MESSAGES Сервер клиенту: EMPTY Клиент серверу: GET MESSAGES Сервер клиенту: EMPTY Клиент серверу: GET MESSAGES Сервер клиенту: EMPTY Клиент и сервер могут гонять туда сюда 1 байт сколько угодно, при этом в БД не будет сделано ни одного запроса. Время итераций тоже может быть какое угодно, например 50-100 мс. Но в какой то момент один из клиентов отправит новую запись: Клиент серверу: SEND "Бла-бла-бла-бла" Сервер добавит запись в БД и сбросит флаги о доставке сообщений всем подключенным клиентам в false и ответит: OK При следующем цикле первого клиента GET MESSAGES, сервер уже ответит не EMPTY, а отправит новые сообщения, после чего опять подождет уведомление о получении и опять отметит что сообщения доставлены... И так далее... То есть получается какая то совсем не нужная возня. Спрашивается: - А нафига это всё, какие то заморочки с диалогами, ответами типа EMPTY? Просто таким способом можно разгрузить БД, не напрягая её постоянными запросами. Представь 20 юзверей с тем же интервалом в 50-100 мс. непрерывно долбят и долбят эту БД, пока она не сдохнет. А ведь она может быть совсем не маленькой и на обработку таблиц сервер может затрачивать нехилые ресурсы. Кеторол, Темпалгин - хорошие обезбаливающие! |
|
23.10.2013, 09:07 | #19 |
Пользователь
Регистрация: 26.12.2009
Сообщений: 95
|
спасибо, попробую
|
|
Похожие темы | ||||
Тема | Автор | Раздел | Ответов | Последнее сообщение |
Клиент + Сервер + MySQL | s_vitaly | Работа с сетью в Delphi | 6 | 29.02.2012 12:43 |
Реализация клиент сервер через delphi и java | Horus92 | Свободное общение | 0 | 15.10.2010 22:27 |
Клиент-сервер+MySQL InterBase проблемы в подключением 2 клиентов. | Vohakisa | Работа с сетью в Delphi | 0 | 21.05.2010 19:28 |
клиент-сервер MySQL | jziiiiiii | БД в Delphi | 10 | 15.02.2008 12:29 |