На самом деле вход не беспарольный, пароль в данном случае заменяется на PIN телефона- наличие PIN-кода на устройстве обязательно, это проверяется при активации.
Поэтому не только владеть телефоном, но и знать PIN-код.
Как я понял, в программе сразу вшито N ключей(смотрел в исходниках программы для android — там 4), а выобрка ключа идет по его слепку (fingerprints), если 1 ключ удастся как-то скомпрометировать, его сразу заменяют на новый(изменяют слепок, который передается при создании авторизационного ключа).
При такой реализации, если браузер закрывает соединение, пользователь никак не узнает, что продолжить это игру ему не удастся, это связано с тем, что на стороне пользователя, нет события закрытия соединения.
Предпочел реализацию без OTP, наверное главной причиной является недостаточное знание фреймворка.
Я запомню вашу модель сетевого взаимодействия, это будет действительно проще и логичней.
на 3.6 он должен пресекать(защитная стратегия) все ваши ходы, насчет ошибки, возможно бот сыграл недостаточно эффективно для той игровой ситуации, но бот только оценивает выгоду куда поставить, в той ситуции значит алгоритм посчитал, что выгодно поставить именно там.
Если я правильно понял, Ваша модель только увеличит производительность приема клиентов, из-за того, что мы выносим accept'ы в разные процессы, а главная причина почему я использовал фигню с take_socket, это для того, чтобы избежать гонок между spawn() и controlling_process().
Да, открытое соединение служит как идентификато, если есть поддержка keep-alive браузер будет слать все get ajax запросы через 1 соединение.
Насчет таймаутов, в заголовках это — Keep-Alive: timeout=25, max=100, если в течение 25 секунд не будет никаких дествий, бразурер должен закрыть соединение, но в браузерах свои дефолтные настройки, и этот заголовок они просто игнорирует, в FF к примеру таймуат — 115 секунд, а это 2 минуты, я думаю хватит подумать.
вот, кстити табличка(тесты не мои):
Opera 11.11 – 120 seconds
Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
IE 9 – 60 seconds
Firefox 4 – 115 seconds
Если так случилось, что сторона пользователя закрыла соединение(корректно), процесс просто выйдет из цикла, и новая игра не начнется, и при этом поле тоже не очистится, получается когда вы делаете ход, вот тогда, и иннициализируется новая игра, но при этом на старом поле(оно ведь не очищено).
Поэтому не только владеть телефоном, но и знать PIN-код.
Не забываем, это просто демонстрационная программа, которая стала для меня хорошим поводом опробовать Erlang.
Я запомню вашу модель сетевого взаимодействия, это будет действительно проще и логичней.
Насчет таймаутов, в заголовках это — Keep-Alive: timeout=25, max=100, если в течение 25 секунд не будет никаких дествий, бразурер должен закрыть соединение, но в браузерах свои дефолтные настройки, и этот заголовок они просто игнорирует, в FF к примеру таймуат — 115 секунд, а это 2 минуты, я думаю хватит подумать.
вот, кстити табличка(тесты не мои):
Opera 11.11 – 120 seconds
Chrome 13 – at least 300 seconds (server closed after 300 second timeout)
IE 9 – 60 seconds
Firefox 4 – 115 seconds
Если так случилось, что сторона пользователя закрыла соединение(корректно), процесс просто выйдет из цикла, и новая игра не начнется, и при этом поле тоже не очистится, получается когда вы делаете ход, вот тогда, и иннициализируется новая игра, но при этом на старом поле(оно ведь не очищено).