Задача такая — есть софт, который должен авторизоваться на сервере (по уникальному секретному ключу, у каждого юзера свой), получать с сервера данные и дальше себе спокойно "ковыряться" до дисконнекта.
Проблема: только один клиент должен иметь возможность использовать ключ. Клиенты могут это делать по-очереди, но пока один не дисконнектнулся, второму будет выдаваться отлуп.
Как это делают без постоянного соединения? Хотелось бы сделать это малой кровью, без гигантских наворотов на сервере. С учетом потенциальных косяков связи и прочего. Короче, чтобы юзер потом не бился в бессильной злобе и не поливал помоями
Короче, где почитать или сразу в сорцы доступные кто-нить ткнет?
з.ы. самое простое, что приходит в голову:
1. Клиент шлет код, сервер возвращает realtime ID, записывает в БД ID клиента и время логина
2. Каждые эН минут клиент шлет пинг серверу со своим ID, сервер обновляет время в БД
3. Если сервак в какой-то момент видит, что кто-то в таймауте, он вытирает его из базы (дисконнект)
4. Если клиент сам дисконнектится, он шлет серверу код и свой ID, сервер из БД удаляет клиента
5. Если клиент2 пытается коннектиться, когда в базе есть запись о первом клиенте, ему дают отлуп
А вот тут засадос
6. Если клиент2 пытается коннектиться после форсмажорного дисконнекта первого клиента, а его по таймауту еще не выписали из БД, он получит отлуп.
Пинговать сервер (п.2) хотелось бы как можно реже.
Извиняюсь за сумбур
Re: Я хз, как это называется... система авторизации :)
Описанный тобой механиз выглядит вполне себе рабочим. Как мне думается, у тебя есть два пути оптимизации простоя при неожиданном разрыве соединения.
Первый путь — уменьшать аймауты в течении которых клиент говорит серверу что он все еще жив. Тут еще можно воспользоваться тем, что операция с сервером так же продлевает жизнь сеанса.
Второй путь — иметь постоянное соединение с сервером и в случае прихода запроса авторизации от нового клиента сервер должен проверить а не отвалился ли клиент.
Лично мне больше нравится второй путь, а с учетом того, что исходя из описания твоего протокола тебе нужно поддерживать максимум одно дополнительное соединение с сервером, то каких-то аргументов против не видно.
Re[2]: Я хз, как это называется... система авторизации :)
Здравствуйте, kaa.python, Вы писали:
KP>Первый путь — уменьшать аймауты в течении которых клиент говорит серверу что он все еще жив. Тут еще можно воспользоваться тем, что операция с сервером так же продлевает жизнь сеанса.
Уменьшение таймаута ведет к увеличению оверхеда (побочные трафик и нагрузка) у сервера
KP>Второй путь — иметь постоянное соединение с сервером и в случае прихода запроса авторизации от нового клиента сервер должен проверить а не отвалился ли клиент. KP>Лично мне больше нравится второй путь, а с учетом того, что исходя из описания твоего протокола тебе нужно поддерживать максимум одно дополнительное соединение с сервером, то каких-то аргументов против не видно.
Вот как раз от постоянного соединения я и хочу уйти.
С постоянным соединением там и думать нечего
Re[3]: Я хз, как это называется... система авторизации :)
Здравствуйте, CyberDemon, Вы писали:
CD>Уменьшение таймаута ведет к увеличению оверхеда (побочные трафик и нагрузка) у сервера
Если со времени последней операции + таймаут не произошло никакого дополнительного обращения к серверу не произошло никакого дополнительного обращения — соединение разорвано.
CD>Вот как раз от постоянного соединения я и хочу уйти. CD>С постоянным соединением там и думать нечего
А чем он не нравится? Ты ведь практически (за исключением портов, но в условии сказано что клиент может быть только 1, а +-1 порт не критично ) никаких ресурсов на поддержание соединения не тратишь. Мне думается — он единственный рабочий вариант в описанной схеме.
Re[3]: Я хз, как это называется... система авторизации :)
Здравствуйте, CyberDemon, Вы писали:
CD>Вот как раз от постоянного соединения я и хочу уйти.
у тебя нет вариантов. либо постоянный коннект, либо частые пинги.
не, можно, конечно, синхронизировать клиентов по времени, чтобы запланированная проверка на дисконнект шла на пару секунд раньше запланированного пинга, но это über-костыль
похоже, что там у тебя веб-сервер. можно сделать long-polling для ожидающих
...coding for chaos...
Re[4]: Я хз, как это называется... система авторизации :)
Здравствуйте, kaa.python, Вы писали:
KP>А чем он не нравится? Ты ведь практически (за исключением портов, но в условии сказано что клиент может быть только 1, а +-1 порт не критично ) никаких ресурсов на поддержание соединения не тратишь. Мне думается — он единственный рабочий вариант в описанной схеме.
Нравится всем, кроме того, что сервер я писал только для небольших реалтайм игрушек и было это давно А сейчас уже совсем не игрушка... Вот и ищу хотя бы что-то среднее. Для начала.
Re[4]: Я хз, как это называется... система авторизации :)
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, CyberDemon, Вы писали:
CD>>Вот как раз от постоянного соединения я и хочу уйти.
F>у тебя нет вариантов. либо постоянный коннект, либо частые пинги. F>не, можно, конечно, синхронизировать клиентов по времени, чтобы запланированная проверка на дисконнект шла на пару секунд раньше запланированного пинга, но это über-костыль F>похоже, что там у тебя веб-сервер. можно сделать long-polling для ожидающих
Вот-вот, веб сервер и хочется сделать, чтобы быстро и круто на этом уровне (на пхп том же)
Re[5]: Я хз, как это называется... система авторизации :)
Здравствуйте, CyberDemon, Вы писали:
CD>Вот-вот, веб сервер и хочется сделать, чтобы быстро и круто на этом уровне
long polling, server sent events, web sockets
постоянный коннект будет лучше, но раз веб-сервер, то вышеперечисленное должно подойти. пинговать — действительно не вариант, особенно, если много клиентов будет, а не 1-5.
CD>(на пхп том же)
зла тебе
...coding for chaos...
Re[6]: Я хз, как это называется... система авторизации :)
Здравствуйте, neFormal, Вы писали:
F>long polling, server sent events
А разве все это не частные случае Push Notifications и как следствие постоянного соединения с сервером?
Типичный пример уведомления клиента о изменении состояния на сервере от Google (т.е. решению можно доверять): Push Notifications поверх XMPP.
Re[6]: Я хз, как это называется... система авторизации :)
Здравствуйте, neFormal, Вы писали:
CD>>Вот-вот, веб сервер и хочется сделать, чтобы быстро и круто на этом уровне
F>long polling, server sent events, web sockets F>постоянный коннект будет лучше, но раз веб-сервер, то вышеперечисленное должно подойти. пинговать — действительно не вариант, особенно, если много клиентов будет, а не 1-5.
CD>>(на пхп том же)
F>зла тебе
Блин, сколько новых незнакомых слов... Спасибо за разъяснения
Re[7]: Я хз, как это называется... система авторизации :)
Здравствуйте, kaa.python, Вы писали:
KP>А разве все это не частные случае Push Notifications и как следствие постоянного соединения с сервером?
да, первые два точно.
просто иногда люди, говоря "постоянное соединение", не знают, как сделать постоянный коннект с веб-сервером. Бывает, делают дополнительных демонов, с которыми держат постоянный коннект, а уж демон сам общается с веб-сервером.
вот и здесь я не думаю, что есть тотальный запрет на удержание соединения. впрочем, могу ошибаться.
