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

Скорость соединения в данном случае не играет большой роли, поскольку идет обмен большим количеством пакетов по несколько байт, а не непрерывная передача потока информации, при которой и может быть достигнута указанная скорость скачивания. В данном случае более критично время отклика. Если чек печатается так долго, то это означает только то, что пакеты проходят далеко не с первого раза, не укладываясь в таймауты ожидания. Для линий связи, подобных xDSL, необходимо реализовывать клиент-серверную прослойку для драйвера, в которой между клиентом и сервером будет передаваться информация о чеке и результат завершения транзакции, а обмен с ККМ будет вестись исключительно на том ПК, к которому эта ККМ подключена. Но такой подход не применим к Вашей ситуации, в которой драйвер работает на сервере и обменивается с ККМ через маппированный на клиента порт. Мы никогда не тестировали и не заявляли работоспособность компоненты в терминальном режиме, тем более на линиях связи, подобных xDSL.

Еще раз повторю, что пропускная способность канала здесь практически никакой роли не играет. Когда говорят о прокускной способности интернет-канала, то подразумевают установившуюся скорость непрерывной передачи данных. Основная проблема, что в Вашем случае не с первого раза происходит получение ответа в течение 50-200 мс с момента посылки пакета. Но какая-то из 25 попыток, осуществляемых компонентой, проходит. Помимо установления соединения, сервер терминалов может добавлять еще какие-нибудь накладные расходы по времени при обмене с клиентом и передаче на него (и получении, соответственно) информации для маппированного последовательного порта. В локальной сети это может быть незаметно, поскольку пинг любого ПК в нормальной сети составляет <1мс и очень стабилен, но в сети xDSL время отклика увеличивается в десятки раз (как Вы писали 20-30 мс, и это среднее время). При работе со сканером речи о таймаутах вообще не идет. У сканера нет как такового протокола обмена данными с ПК. После прочтения он просто передает строку из полутора десятков байт в порт и "забывает" об этом. На ПК работа с портом настроена таким образом, что программа реагирует на любую полученную в порт информацию. Получается, что информация о считанном штрих-коде может передаваться от клиента к серверу хоть час, и никаких накладок не будет, кроме длительной реакции программы на считанный сканером код.

По поводу Citrix, к сожалению, ничего подсказать не могу. Если только кто-то из пользователей компоненты поделится информацией о построении таких систем.

Наверное мы друг друга просто не понимаем. Попробуйте скачать один файл объемом 10 Мб и множество файлов каждый по 10 байт, но общим объемом 10 Мб, с одного и того же сервера. Если время скачивания будет одно и то же, то я соглашусь с вашим определением пропускной способности интернет-канала.

Таймауты, к сожалению, не регулируются.

Попробуйте сделать маппинг COM портов используя софт стороннего производителя, например Taltech TCP-Com v4.1.3 . У меня по нему работают другие усторйства, тоже передающие много меких пакетов и требующие реалтайма. Очень неплохо работает, причём из любой точки мира.