Подскажите, если кто-то уже сталкивался, насколько неидеально в Win 2003 Server реализовано перенаправление последовательных портов? В чем выражается эта неидеальность?
Подходит ли существующий функционал для ККМ Prim-07K и Mercury 114.1F?
P.S. Терминальная сессия будет запускаться для DOS-приложения, написанного на Borland C++ 4.5
Периферия на com-портах
В win2003server перенаправление com портов сделано нормально, я использовал перенаправление на win XP и всё работало замечательно. Тестировал модем, фискальный регистратор Штрих-М ФР.
Если использовать клиентов WTWare, то возникают проблемы... тэстировал WTWare давно, если правильно помню, была проблема с сигналом "hold". Но могу ошибаться
это было больше года назад
P.S. Терминальная сессия для DOS приложения - это плохо! Если есть возможность замени на Win приложение!
Если использовать клиентов WTWare, то возникают проблемы... тэстировал WTWare давно, если правильно помню, была проблема с сигналом "hold". Но могу ошибаться
это было больше года назад P.S. Терминальная сессия для DOS приложения - это плохо! Если есть возможность замени на Win приложение!
А багрепорт разработчикам WTware не посылался?Ejean писал(а):В win2003server перенаправление com портов сделано нормально, я использовал перенаправление на win XP и всё работало замечательно. Тестировал модем, фискальный регистратор Штрих-М ФР.
Если использовать клиентов WTWare, то возникают проблемы... тэстировал WTWare давно, если правильно помню, была проблема с сигналом "hold". Но могу ошибаться
Не могу. Часть кода по обмену данными с чужой железкой через com от мена разработчиками специально была скрыта в lib'у. Поэтому перекомпилить приложение в 32битную версию не получится. А протокол обмена с железкой разработчики не отдадут (иначе их софт никто не купит, будут все свой писать) - не зря ж они его так старательно в lib'у прятали. У меня старая неподдерживаемая разработчиком версия софта (потому под DOS), я поддерживаю ее локально уже 2,5 года потому что у руководства нет денег на win-версию, половина кода в ней скрыта в библиотеки, документации нет, и то что есть - было с трудом куплено за нехилые бабки после прекращения поддержки разработчиком.Ejean писал(а):P.S. Терминальная сессия для DOS приложения - это плохо! Если есть возможность замени на Win приложение!
Тогда, надеюсь АКА не обидется, лучше использовать Win95 с установленным клиентом терминала.BMSerg писал(а):Не могу.
1) Лицензионная цена таже
2) Нет проблем с перенаправлением Com портов
3) Нет проблем с DOS приложениями в терминале
4) Нет проблемы не корректной работы DOS приложения с портами.
Если хватит знаний и/или терпения настроишь загрузку Win95 по сети...
Для задач таких как 1С открывать терминальный сеанс.
-
Гость
Даже с теми что работают в графическом режиме?Ejean писал(а):[skiped]BMSerg писал(а):Не могу.
3) Нет проблем с DOS приложениями в терминале
Хватит и того и другогоEjean писал(а): 4) Нет проблемы не корректной работы DOS приложения с портами.
Если хватит знаний и/или терпения настроишь загрузку Win95 по сети...
Для задач таких как 1С открывать терминальный сеанс.
Тут сразу другие вопросы:
1) Если я правильно понял, с Win95 машины стартует родной win32 терминальный клиент 2003 сервера, в нем запускается мое DOS-приложение и корректно работает с подцепленными к com-портам терминальной машины железкой и фискальным регистратором?
2) win95 или win95osr2?
3) чем хуже цитрикс + его родной dos-клиент?
1) Ты не правильно понял! Я имел ввиду запускать DOS приложения под WIN95. Т.е. на локальном компьютере, а не в терминале! (Win95 можно заменить на WinXP если денег не жадкоAnonymous писал(а):Даже с теми что работают в графическом режиме?
). Перенаправлять COM порты в этом случае не понадобиться Терминал использовать для Win приложений.
2) win95osr2 - лучше
3) Я не использовал Цитрикс Метафрэйм, я использую только лицензионный софт, а Цитрикс слишком дорогой! Если в нём и есть небольшие плюсы, то они НЕ СТОЯТ ТАКИХ денег
Я не совсем представляю общую задачу, если ты опишешь её подробней, может каким советом и помогу.
P.S. Когдато давным давно, когда фирма работала только в DOS, я использовал загрузку по сети именно DOS, SUBST-ом мапил сетевой диск как A и COMSPEC-ом указывал где лежит command.com. Затем работал как в обычном DOS.
Когда начинал использовать RDP терминалы, находил клиента для DOS.
Дано:
1) Есть программа управления автоматизированным переговорным пунктом под DOS 6.22 и выше, работающая в графическом режиме и напрямую обращающаяся к com-портам, к которым подцеплен фискальный регистратор и коммутатор телефонных кабин. Разработка сторонняя, частично исходники были открыты разработчиком. DOS-версия ПО разработчиком не поддерживается уже несколько лет.
2) Протокол обмена данными с коммутатором закрыт, является собственностью разработчика и переписать прогу под винду я не могу. Могу вносить изменения в интерфейс и пр.
3) Рабочие станции (486, P1 с 16-32 MB ОЗУ) стоят в отделениях связи по городу и области, отделения подцеплены к корпоративной локалке через dsl
Задача:
Т.к. аппаратно-программный комплекс предназначен в т.ч. и для приема платежей (как минимум за переговоры), встала задача переноса данных о платежах (по сути первичные документы) в БД КИС. Соответственно требуется надежное хранилище файлов с инфой о принятых платежах и либо реал-тайм, либо с задержкой на операционный день выгрузка данных о платежах из внутреннего фформата файлов проги в SQL-бд КИС
Теоретическое решение:
Поднять прогу на терминальном сервере и организовать терминальный доступ с бездисковых станций (dhcp через dhcp-relay на dsl-модемах, bootp). Получаем для каждого отделения хранение данных в отдельной папке на сервере (надежность 100%) и пакетная выгрузка в БД КИС ночью либо при пересменке.
Нерешенные проблемы:
1) Возможно ли поднять DOS-приложение, работающее в графическом режиме и юзающее com-порты на терминальном сервере Win2003 (или любом другом, лишь бы работало)?
2) Терминальный клиент с надежно работающим перенаправлением com-портов (тоже любой, в принципе)
Если такая возможность есть и испытания пройдут удачно, требуемый софт честно купится
ЗЫ Положе пора перебираться в приват, от темы скоро окончательно уйдем...
1) Есть программа управления автоматизированным переговорным пунктом под DOS 6.22 и выше, работающая в графическом режиме и напрямую обращающаяся к com-портам, к которым подцеплен фискальный регистратор и коммутатор телефонных кабин. Разработка сторонняя, частично исходники были открыты разработчиком. DOS-версия ПО разработчиком не поддерживается уже несколько лет.
2) Протокол обмена данными с коммутатором закрыт, является собственностью разработчика и переписать прогу под винду я не могу. Могу вносить изменения в интерфейс и пр.
3) Рабочие станции (486, P1 с 16-32 MB ОЗУ) стоят в отделениях связи по городу и области, отделения подцеплены к корпоративной локалке через dsl
Задача:
Т.к. аппаратно-программный комплекс предназначен в т.ч. и для приема платежей (как минимум за переговоры), встала задача переноса данных о платежах (по сути первичные документы) в БД КИС. Соответственно требуется надежное хранилище файлов с инфой о принятых платежах и либо реал-тайм, либо с задержкой на операционный день выгрузка данных о платежах из внутреннего фформата файлов проги в SQL-бд КИС
Теоретическое решение:
Поднять прогу на терминальном сервере и организовать терминальный доступ с бездисковых станций (dhcp через dhcp-relay на dsl-модемах, bootp). Получаем для каждого отделения хранение данных в отдельной папке на сервере (надежность 100%) и пакетная выгрузка в БД КИС ночью либо при пересменке.
Нерешенные проблемы:
1) Возможно ли поднять DOS-приложение, работающее в графическом режиме и юзающее com-порты на терминальном сервере Win2003 (или любом другом, лишь бы работало)?
2) Терминальный клиент с надежно работающим перенаправлением com-портов (тоже любой, в принципе)
Если такая возможность есть и испытания пройдут удачно, требуемый софт честно купится
ЗЫ Положе пора перебираться в приват, от темы скоро окончательно уйдем...
Дополнительные вопросы:
1) насколько надёжна связь через DSL? И как часто случаются разрывы? Нужно учитывать, что в этот момент отделение ВООБЩЕ работать не будет при переходе на терминальный режим.
2) сколоко рабочих мест в каждом пункте? 1 или 10?
Ответы:
Из личного опыта: многие графические программы под DOS нестабильно работают в Windows 2000 и более поздних, тем более напрямую обращающиеся к оборудованию!!!
1) Если лишь бы работоло то - да
2) Это нужно только пробовать! RDP клиент под винду с моим оборудованием работал нормально. Но опять таки всё зависит от качества канала и принципа работы оборудования. Короче от большых таймаутов может связь разрываться. В локалке будет нормально, но через DSL...
Вывод: я бы не стал перенаправлять COM порты. Не знаю уровень знаний по программированию уважаемого BMSerg. Но я бы сделал серверное приложение на сервере и клиентское на рабочих компах которые и передавали через сеть данные в заданные промежутки времени или по команде пользователя. Шифрация пакетов и/или VPN взависимости от требований безопасности.
1) насколько надёжна связь через DSL? И как часто случаются разрывы? Нужно учитывать, что в этот момент отделение ВООБЩЕ работать не будет при переходе на терминальный режим.
2) сколоко рабочих мест в каждом пункте? 1 или 10?
Ответы:
Из личного опыта: многие графические программы под DOS нестабильно работают в Windows 2000 и более поздних, тем более напрямую обращающиеся к оборудованию!!!
1) Если лишь бы работоло то - да
2) Это нужно только пробовать! RDP клиент под винду с моим оборудованием работал нормально. Но опять таки всё зависит от качества канала и принципа работы оборудования. Короче от большых таймаутов может связь разрываться. В локалке будет нормально, но через DSL...
Вывод: я бы не стал перенаправлять COM порты. Не знаю уровень знаний по программированию уважаемого BMSerg. Но я бы сделал серверное приложение на сервере и клиентское на рабочих компах которые и передавали через сеть данные в заданные промежутки времени или по команде пользователя. Шифрация пакетов и/или VPN взависимости от требований безопасности.
тема закрыта?BMSerg писал(а):Дано:
Теоретическое решение:
Поднять прогу на терминальном сервере и организовать терминальный доступ с бездисковых станций (dhcp через dhcp-relay на dsl-модемах, bootp). Получаем для каждого отделения хранение данных в отдельной папке на сервере (надежность 100%) и пакетная выгрузка в БД КИС ночью либо при пересменке.
Нерешенные проблемы:
1) Возможно ли поднять DOS-приложение, работающее в графическом режиме и юзающее com-порты на терминальном сервере Win2003 (или любом другом, лишь бы работало)?
2) Терминальный клиент с надежно работающим перенаправлением com-портов (тоже любой, в принципе)
Если такая возможность есть и испытания пройдут удачно, требуемый софт честно купится
По поводу проброса СОМ через IP - задача решена для Win полностью. И начальное тестирование прошло. Остановилось продвижение дальше, т.к. заработала проброска под клиентом.
Хотя для желающих получить доступ по смарт-картам текущее состояние непоможет, а виртуальные порты - могут.
Можно попробывать на ваших каналах. С Win-клиентом для начала. А потом может что-то и привяжется к WTWare...
Это уж как АКА с планами решит... Мы смогли обеспечить задержку в локалке примерно 2-5 мс между передачей данных (имеется ввиду по 1 байту. Есть такой алгоритм Найгла, который это запрещает при малых потоках) с порта железного в порт виртуальный на сервере или вирт-вирт.
И еще - насколько сложен ваш протокол? Вы не думали снять дамп и разобрать? Не думаю, что разработчик там накрутил что-то слишком сложное.... Это вполне решаемая задача. Очобенно, если есть рядом железо для проб и ошибок...