принято. за выходные оттестирую.
Нам это надо?
в моей реализации на суровые настоящие не надо. надож торговый софт пилить, чтобы умел узверей авторизовывать ((
юзеры имели бы смылс, в такой реализации: стоит машина с атолсервер, на ней стокасс, на рабочих местах стокасс прописано бить на атолсервер, а на какую ККМ обрабатывается через пару юзер/пассворд.
по факту жеж схема подключения сейчас такая: одно физическое рабочее место кассира, к этому рабочему месту по усб подключена ккм, это рабочее место цепляется по рдп к серванту, сервант общается с ккм подключенной к физическому рабочему месту кассира. в такой схеме даже поддержка нескольких ккм атолсервером уже избыток для меня.
как бы согласен, надо смотреть в будущее, и тэдэитэпэ, пусть будет, но использовать пока нет необходимости.
И ещё в 10.8.0.0 появилась "atol-fptr-rpc-server"
походу чтото типо шрихового фр сервера.
жутко сомневаюсь что это будет быстрее чем атолвеб
обоснование:
все мы помним, что тормоза при печати чека от большого пинга между физической ккм (чем бы она не слушала входящий трафик) и местом откуда отправляются данные на эту ккм (читаем РДП сервак)
1. в схеме атолвеб трафик шустро с РДП сервака на атолвеб проскакивает (http не так критично относиться к большому пингу). далее атолвеб кидает эти данный прямо на ккм в рамках одной физической среды прямо в порт. результат - чек выскочил шустро.
2. в любой схеме перенаправления порта при высоком пинге чек всегда будет тормозюкать. при пробросе средствами рдп сильнее, на ser2net меньше, но тормозюкать будет. результат - чек будет выходить медленнее чем через атолвеб.
практика конешно покажет истину. но в теории пока так.
принято. за выходные оттестирую.
[quote]
Нам это надо?
[/quote]
в моей реализации на суровые настоящие не надо. надож торговый софт пилить, чтобы умел узверей авторизовывать ((
юзеры имели бы смылс, в такой реализации: стоит машина с атолсервер, на ней стокасс, на рабочих местах стокасс прописано бить на атолсервер, а на какую ККМ обрабатывается через пару юзер/пассворд.
по факту жеж схема подключения сейчас такая: одно физическое рабочее место кассира, к этому рабочему месту по усб подключена ккм, это рабочее место цепляется по рдп к серванту, сервант общается с ккм подключенной к физическому рабочему месту кассира. в такой схеме даже поддержка нескольких ккм атолсервером уже избыток для меня.
как бы согласен, надо смотреть в будущее, и тэдэитэпэ, пусть будет, но использовать пока нет необходимости.
[quote]
И ещё в 10.8.0.0 появилась "atol-fptr-rpc-server"
[/quote]
походу чтото типо шрихового фр сервера.
жутко сомневаюсь что это будет быстрее чем атолвеб
обоснование:
все мы помним, что тормоза при печати чека от большого пинга между физической ккм (чем бы она не слушала входящий трафик) и местом откуда отправляются данные на эту ккм (читаем РДП сервак)
1. в схеме атолвеб трафик шустро с РДП сервака на атолвеб проскакивает (http не так критично относиться к большому пингу). далее атолвеб кидает эти данный прямо на ккм в рамках одной физической среды прямо в порт. результат - чек выскочил шустро.
2. в любой схеме перенаправления порта при высоком пинге чек всегда будет тормозюкать. при пробросе средствами рдп сильнее, на ser2net меньше, но тормозюкать будет. результат - чек будет выходить медленнее чем через атолвеб.
практика конешно покажет истину. но в теории пока так.