Установил клиент. Запускаю синхронизацию с сервером. Как доходит до запроса новых пользователей задумывается. Сижу под 33600 битами в секунду. Сколько, обычно, занимает этот процесс?
Здравствуйте, Древлянин, Вы писали:
Д>Установил клиент. Запускаю синхронизацию с сервером. Как доходит до запроса новых пользователей задумывается. Сижу под 33600 битами в секунду. Сколько, обычно, занимает этот процесс?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Древлянин, Вы писали:
Д>>Установил клиент. Запускаю синхронизацию с сервером. Как доходит до запроса новых пользователей задумывается. Сижу под 33600 битами в секунду. Сколько, обычно, занимает этот процесс?
AVK>Первый раз минут 15-20.
Нужно об этом где-нибудь предупредить пользователей, а то ведь не каждый дождётся.
Здравствуйте, Древлянин, Вы писали:
AVK>Первый раз минут 15-20.
Д>Нужно об этом где-нибудь предупредить пользователей, а то ведь не каждый дождётся.
Умнее было бы тянуть только тех пользователей чьи сообщения приехали при синхронизации. Т.е. смотрим в БД каких юзеров нет. Составляем список и передаем его на сервер. А тот возвращает юзеров. При этом и проблемы с версиями уйдут.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
Д>>Нужно об этом где-нибудь предупредить пользователей, а то ведь не каждый дождётся.
VD>Умнее было бы тянуть только тех пользователей чьи сообщения приехали при синхронизации. Т.е. смотрим в БД каких юзеров нет. Составляем список и передаем его на сервер. А тот возвращает юзеров. При этом и проблемы с версиями уйдут.
Не получицца. Проблемы опять те же — текущая схема синхронизации не позволяет этого чисто теоретически. Т.е. сервер не знает что у юзера есть в БД, а чего нету. Слать каждый раз пользователей для всех забираемых сообщений еще хуже чем сейчас.
Здравствуйте, AndrewVK, Вы писали:
AVK>Не получицца. Проблемы опять те же — текущая схема синхронизации не позволяет этого чисто теоретически. Т.е. сервер не знает что у юзера есть в БД, а чего нету. Слать каждый раз пользователей для всех забираемых сообщений еще хуже чем сейчас.
Что не получится? Будет та самая двухфазная схема, но только для пользователей. Думаю, это раз плюнуть сделать.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Что не получится? Будет та самая двухфазная схема, но только для пользователей. Думаю, это раз плюнуть сделать.
AVK>Не, для пользователей так не получится. Пользователей, в отличие от сообщений, надо выкачивать всех.
Повтояю тебе в который раз. Кидая заявления турдись их обосновывать. На такие же заявления я тебе буду просто отвечть: Ты не правл.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>Что не получится? Будет та самая двухфазная схема, но только для пользователей. Думаю, это раз плюнуть сделать.
AVK>>Не, для пользователей так не получится. Пользователей, в отличие от сообщений, надо выкачивать всех.
VD>Повтояю тебе в который раз. Кидая заявления турдись их обосновывать. На такие же заявления я тебе буду просто отвечть: Ты не правл.
Влад, ну я устал уже тебе расписывать проблемы каждый раз когда ты об этом вспомнил. Тебе кажется что там все просто. Тебе разъясняешь что не выйдет. Ты вроде бы успокаиваешься, потом опять забываешь и начинается поновой. Ну не буду же я тебе каждый раз опять по новой разжевывать.
Если ты будешь выкачивать пользователей в соответствии с передаваемыми сообщениями, то тебе придется качать их на клиента всякий раз когда от них будут появляться сообщения, поскольку сервер не знает какие юзеры есть в клиентской базе, а каких нет. Единственное что тут можно придумать — накладывать дополнительные ограничения на список пользователей в соответствии со списком полученных сообщений, но при этом один черт с клиента нужно кидать список сообщений, которых он в прошлый раз утащил. А это приведет к тому что запрос и пользователей и сообщений нужно заворачивать в одну транзакцию. Все это не очень радует. Да и не стоит оно того — трафик, генерируемый пользователями, маленький. 15 минут при первом обращении вполне можно подождать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Влад, ну я устал уже тебе расписывать проблемы каждый раз когда ты об этом вспомнил.
Я не видел ни одного обяснения. Одини заявления. Если ты объяснял, то дай ссылку, и проблема будет решена.
AVK> Тебе кажется что там все просто. Тебе разъясняешь что не выйдет.
Вот разяснений, то и не видать.
AVK> Ты вроде бы успокаиваешься, потом опять забываешь и начинается поновой.
Ну, может я и забыл, но что-то мне кажется, что ты особо и не разяснял.
AVK> Ну не буду же я тебе каждый раз опять по новой разжевывать.
AVK>Если ты будешь выкачивать пользователей в соответствии с передаваемыми сообщениями, то тебе придется качать их на клиента всякий раз когда от них будут появляться сообщения, поскольку сервер не знает какие юзеры есть в клиентской базе, а каких нет.
Мне кажтся ты профильтровал, что я тебе говорил. Еще раз:
В базе уже есть каой-то список пользователей и какой-то сообщений. Не трудно найти список пользоватлей (их ID) которых нет в локальной БД, но сообщения которых в ней присуствуют. Далее все просто. Синхноризируемся. Получаем новые сообщения. Проверяем есть ли такие ID в локальной БД. И если нет, посылаем на сервер запрос в котором перечислены ID требуемых юзеров. Далее плучаем юзеров и заносим их в БД. Отдельно можно сделать процедуру корректирующую локальную БД на случай расинхронизации или перехода со старой версии.
AVK> Единственное что тут можно придумать — накладывать дополнительные ограничения на список пользователей в соответствии со списком полученных сообщений, но при этом один черт с клиента нужно кидать список сообщений
Зачем сообщеий? Только требуемых юзров. Такой список будет микроскопическим.
AVK>, которых он в прошлый раз утащил. А это приведет к тому что запрос и пользователей и сообщений нужно заворачивать в одну транзакцию. Все это не очень радует. Да и не стоит оно того — трафик, генерируемый пользователями, маленький.
Ты как будно в другом мире живешь. Постоянно идут вопли о выкачке тонны старых юзеров и о том, что выкачка юзеров занимает времени больше, чем сообщений.
AVK>15 минут при первом обращении вполне можно подождать.
Да мой диалап за 15 минут 2 раза дисконектнется. Да и зачем ждать, то? Дурь наша, а страдают все. Зачем нам отпугивать юзеров. Ведь он подождав 5 минут может решить, что программа вообще не работат, грохнуть и начать развавать слухи, что Хоум дерьмо.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В базе уже есть каой-то список пользователей и какой-то сообщений. Не трудно найти список пользоватлей (их ID) которых нет в локальной БД, но сообщения которых в ней присуствуют. Далее все просто. Синхноризируемся. Получаем новые сообщения. Проверяем есть ли такие ID в локальной БД. И если нет, посылаем на сервер запрос в котором перечислены ID требуемых юзеров. Далее плучаем юзеров и заносим их в БД.
Все красиво, пока не вспоминаем об одной вещи — профили пользователей могут меняться.
AVK>> Единственное что тут можно придумать — накладывать дополнительные ограничения на список пользователей в соответствии со списком полученных сообщений, но при этом один черт с клиента нужно кидать список сообщений
VD>Зачем сообщеий? Только требуемых юзров. Такой список будет микроскопическим.
Клиент не может знать каких пользователей ему надо, поскольку он не знает какие пользователи менялись.
VD>Ты как будно в другом мире живешь. Постоянно идут вопли о выкачке тонны старых юзеров
Ну это надо просто переделать для юзеров генерацию версий, как это сделано для сообщений.
Здравствуйте, AndrewVK, Вы писали:
AVK>Все красиво, пока не вспоминаем об одной вещи — профили пользователей могут меняться.
Печально.
AVK>Клиент не может знать каких пользователей ему надо, поскольку он не знает какие пользователи менялись.
ОК. Делаем два списка. Один пользователей которых нет вообще. А другой всех пользователей из прибывших сообщений кроме новых. Из второго списка сервер отдает только новых из первого всех.
VD>Ты как будно в другом мире живешь. Постоянно идут вопли о выкачке тонны старых юзеров
AVK>Ну это надо просто переделать для юзеров генерацию версий, как это сделано для сообщений.
15-ти минутной задержки при первом общении с сервером — это не исключит.
И вообще я старонник алгоритмического решения проблем.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Клиент не может знать каких пользователей ему надо, поскольку он не знает какие пользователи менялись.
VD>ОК. Делаем два списка. Один пользователей которых нет вообще. А другой всех пользователей из прибывших сообщений кроме новых. Из второго списка сервер отдает только новых из первого всех.
Здравствуйте, AndrewVK, Вы писали:
AVK>>Клиент не может знать каких пользователей ему надо, поскольку он не знает какие пользователи менялись.
VD>ОК. Делаем два списка. Один пользователей которых нет вообще. А другой всех пользователей из прибывших сообщений кроме новых. Из второго списка сервер отдает только новых из первого всех.
AVK>Не понял мысли
При передаче новых сообщений мы смотрим нет ли в них измененных сообщений. Если есть кладем ID измененного юзера в пакет. Далее на клиенте я подключаю к этому списку тех юзверей который у меня еще нет в БД и прошу сервер отдаль мен их.
Таким образом. Новые и изменненые пользователи выкачиватья будут только когда в этом появится необходиомость и маельнкими порциями.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>При передаче новых сообщений мы смотрим нет ли в них измененных сообщений.
А при чем тут измененные сообщения? Ничего опять не пойму.
VD>Если есть кладем ID измененного юзера в пакет. Далее на клиенте я подключаю к этому списку тех юзверей который у меня еще нет в БД и прошу сервер отдаль мен их.
