На главную страницу Версия-Т
VTSoft.ru

АМС-100К+чековый онлайн+сервер терминалов

RSS
АМС-100К+чековый онлайн+сервер терминалов, очень большая задержка при печати чека
 
#1
23.11.2006 18:01:12
В базе данных 1С (dbf), в режиме чековый онлайн отлично работают две кассы АМС-100К, версия компаненты 1.1.0.8. Имеется удалённый магазин, который работает через сервер терминалов (Windows 2003 sp1+все обновления) в одной базе данных. Связь осуществляется через Интернет по технологии ADSL (средний пинг 20-30 мс). Мне поставили задачу подключить в этом магазине кассу к 1С. Проблем при подключении не возникло. Проблемма в том, что чек (всего одна покупка) печатается порядка минуты, всё это время 1С передаёт данные в кассу: в 1С пишется "выполняется обработка", на экране кассы со временем меняются данные - сначало "1" (после нажатия ФЦ-1-ВВ), затем маленький нолик слева (кажется признак записи в ФП) и т.д. За это время, что печатается чек, при существующей скорости можно несколько Мб скачать. Причём в этом же магазине достаточно быстро и комфортно работает сканер штрих-кода, подключенный через COM порт. Настройки COM портов стандартные, ключ Guardant Fidus LPT подключен к серверу. Вопрос: как с этим бороться?
 
 
 
#2
24.11.2006 12:07:56
Скорость соединения в данном случае не играет большой роли, поскольку идет обмен большим количеством пакетов по несколько байт, а не непрерывная передача потока информации, при которой и может быть достигнута указанная скорость скачивания. В данном случае более критично время отклика. Если чек печатается так долго, то это означает только то, что пакеты проходят далеко не с первого раза, не укладываясь в таймауты ожидания. Для линий связи, подобных xDSL, необходимо реализовывать клиент-серверную прослойку для драйвера, в которой между клиентом и сервером будет передаваться информация о чеке и результат завершения транзакции, а обмен с ККМ будет вестись исключительно на том ПК, к которому эта ККМ подключена. Но такой подход не применим к Вашей ситуации, в которой драйвер работает на сервере и обменивается с ККМ через маппированный на клиента порт. Мы никогда не тестировали и не заявляли работоспособность компоненты в терминальном режиме, тем более на линиях связи, подобных xDSL.
 
 
 
#3
24.11.2006 12:50:12
Но ведь пропускная способность канала на много выше чем скорость обмена данными через com порт с кассой, и даже учитывая те большие накладные расходы о которых Вы говорите ("поскольку идет обмен большим количеством пакетов по несколько байт"), я думаю скорость должна быть приемлимой, поправьте меня если я ошибаюсь. Каковы эти таймауты ожидания? Судя по всему у сканера эти таймауты значительно больше.
Про то, что Вы не заявляли работосспособность компоненты в терминальном режиме я в курсе. Я собственно ни каких притензий и не имею. Просто помощи прошу, может у кого решение есть, советы? Потому как на форуме частенько встречаются сообщения о подобных связках ккм+1С+терминал и вроде как некоторые добиваются успеха в этой области. Может citrix побыстрей обрабатывает маппинг портов? Хотя судя по этому сообщению http://vtsoft.ru/support/forum/read.php?FID=2&TID=719
не на много :(
 
 
 
#4
24.11.2006 14:38:45
Еще раз повторю, что пропускная способность канала здесь практически никакой роли не играет. Когда говорят о прокускной способности интернет-канала, то подразумевают установившуюся скорость непрерывной передачи данных. Основная проблема, что в Вашем случае не с первого раза происходит получение ответа в течение 50-200 мс с момента посылки пакета. Но какая-то из 25 попыток, осуществляемых компонентой, проходит. Помимо установления соединения, сервер терминалов может добавлять еще какие-нибудь накладные расходы по времени при обмене с клиентом и передаче на него (и получении, соответственно) информации для маппированного последовательного порта. В локальной сети это может быть незаметно, поскольку пинг любого ПК в нормальной сети составляет <1мс и очень стабилен, но в сети xDSL время отклика увеличивается в десятки раз (как Вы писали 20-30 мс, и это среднее время). При работе со сканером речи о таймаутах вообще не идет. У сканера нет как такового протокола обмена данными с ПК. После прочтения он просто передает строку из полутора десятков байт в порт и "забывает" об этом. На ПК работа с портом настроена таким образом, что программа реагирует на любую полученную в порт информацию. Получается, что информация о считанном штрих-коде может передаваться от клиента к серверу хоть час, и никаких накладок не будет, кроме длительной реакции программы на считанный сканером код.

По поводу Citrix, к сожалению, ничего подсказать не могу. Если только кто-то из пользователей компоненты поделится информацией о построении таких систем.
 
 
 
#5
24.11.2006 15:27:35
Пропускная способность канала напрямую зависит от задержек и наоборот. "Но какая-то из 25 попыток, осуществляемых компонентой, проходит" Если у меня на канале было бы столько ретрэйнов на пакет, это было бы соединение сравнимо с обычным диалапом, что совсем не так. Но дело не в этом. Оснавная проблемма понятна - задержки. Таймауты на кассе или в компоненте хоть как нибудь могут регулироваться?
 
 
 
#6
24.11.2006 15:40:36
Наверное мы друг друга просто не понимаем. Попробуйте скачать один файл объемом 10 Мб и множество файлов каждый по 10 байт, но общим объемом 10 Мб, с одного и того же сервера. Если время скачивания будет одно и то же, то я соглашусь с вашим определением пропускной способности интернет-канала.

Таймауты, к сожалению, не регулируются.
 
 
 
#7
24.11.2006 16:05:13
Ну почему-же не понимаем? Во втором случае вашего примера мы получим большие накладные расходы и скорость передачи полезных нам данных будет меньше, т. к. размер заголовка IP пакета (служебные данные) постоянен при разном объёме передаваемой информации в пакете. А вообще, разве все данные (в том числе и маппинг com портов) между сервером терминалов и клиентов передаются не по протоколу прикладного уровня RDP, следовательно ему вообще побаробану на TCP/IP, просто сам стэк протоколов TCP/IP обеспечивает передачу данных на своём уровне и если какие-то пакеты и теряются, то TCP (протокол контроля передачи) иправляет это на общем фоне (данные картинки, клавиатуры, мыши, портов, принтеров и т.д.)
По поводу таймаутов - жаль, похоже у меня тупиковая ситуация.
 
 
 
#8
06.01.2007 02:07:01
Попробуйте сделать маппинг COM портов используя софт стороннего производителя, например Taltech TCP-Com v4.1.3 . У меня по нему работают другие усторйства, тоже передающие много меких пакетов и требующие реалтайма. Очень неплохо работает, причём из любой точки мира.

 
 
 
#9
11.01.2007 12:29:20
Можно попробовать использовать DCOM для подключения кассы, но придётся переписывать обработку.

А вообще самая здравая идея - просить разработчиков за отдельную плату написать DLL в двух частях со связкой через IP обмен.
Думаю, что такая вещь многим пригодится.
 
 
 
#10
12.01.2007 15:09:07
Кстати, тут недавно столклулся с некоторой похожей проблемой. В локальной сети с несколькими роутерами передача файла по FTP занимала очень много времени, точнее основное время уходило на открытие соединения, так как система для локальных соединений пыталась разрешить его адрес в символьное представление (и соответственно ожидала ответа от DNS сервера).
Вполне вероятно, что у вас может быть что-то подобное.
Это можно проверить просто, замкнув выводы TXD и RXD последовательного порта, и посмотреть, что сколько времени будет уходить у терминала (в котором открыть этот порт на сервере) на обработку передачи символа туда-обратно, а также на открытие порта терминалом.
Потому как в базе роутера информация о соединении хранится какое-то время, а потом сбрасывается, если в порт долго ничего не передаётся, то процесс установки TCP соединения может идти заново.
Пакеты же PING передаются без задержек и анализа, также и данные окна терминала, которые обновляются с каждым действием.

Удачи.