Добрый день.
Несколько раз на форуме встречал просьбу предоставить описание работы контроллера в режиме web, но как правило эти просьбы не увенчались успехом поскольку что-то еще не задокументировано или готовится к публикации.
Отсюда вопрос - есть ли подвижки в этом вопросе?
На текущий момент у нас есть около десятка конвертеров, за которыми скрыты несколько сот контроллеров.
Сейчас работа построена на режиме Server, и с каждым конвертером приходится держать устойчивое соединение (которое как показала практика, лучше всего переподключать раз в 2-3 минуты), это обеспечивает возможность в пределах 1-2 сек открыть любую дверь через обращение по АПИ системы.
Также периодически ( раз в 15 сек), приходится опрашивать все контроллеры и на предмет наличия событий, актуальности БД ключей (удаление/добавление) и отражение этого всего в СУБД.
В периоды таких опросов в многопоточной реализации ЦПУ загружается на 100% на раз, даже на очень неплохих Windows-системах.
В *nix системах ситуация немного лучше - но тоже не все гладко.
Система построенная на чистом REST API обрабатывает 2.5 млн запросов в сутки, это немного туговато.
Поэтому режим WEB, даже в части лишь событий существенно облегчил бы этот момент.
С чем столкнулся сейчас: в режиме Web конвертер шлет приветствие, которое в каждой посылке разное - т.е. данные скорее всего содержат некие опорные данные, которые в сочетании с ключом / кодом авторизации / номером могут быть правильно декодированы серверной стороной. Но как они закодированы - нигде не написано, что очень странно.
Можно дампить запрос, но меняется только часть закодированных данных, а без алгоритма шифрования/дешифрования ловить там особо нечего
POST http://*******/events.php HTTP/1.1
Host: *******
User-Agent: Z397WEB
Conection: close
Cache-Control: max-age=0
Content-Type: multipart/form-data; boundary=18113960011
x-ser-n: 0*****4
x-auth-key: 5******2
x-fw-ver: 3.0.48
x-next-srv: 0
Content-Length: 180
--18113960011
Content-Disposition: form-data; name="message"; filename="data"
Content-Type: application/octet-stream
=Хц< #Ё%%К?bа?юRяя~ўДЬ Pgяёc???g?,Tи'N
--18113960011--
=Хц< #Ё%%К?bа?юRяя~ўДЬ Pgяёc???g?,Tи'N
Можно ли увидеть пример реализации серверной части, хотя бы в части декодирования/кодирования, тогда уже на основе дампов можно будет хоть как-то разгрузить конвертеры и серверный блок?
