Здравствуйте, Valery A. Boronin, Вы писали:
VAB>почему-то я решил что именно на клиентах стоят МОКС... еще раз просмотрел ветку — нигде не написано обратного (цитата кстати ниже). Обрисовали бы целиком картину?
Нет. МОКСы стоят именно на концентраторах. Немного истории..
Эта огромная задача была реализованна еще при совдепе и работала на ЕСках(насколько я помню) и до сих пор работает. Сейчас ее "портировали" под ДОС/Win. Это огромная пирамида концентраторов, в каждом большом регионе стоят майнфреймы. Как я уже говорил каждый концентратор несет на себе от 8 и более портов/клиентов. Сейчас у меня их гдето штук 20. В отличие от клиентов концентраторы под Win32. При настройке канала на клиента я уже пишу COM 10 и т.д. Это хорошо. Все проблема в клиентах, мало того что они под ДОС и ломятся на 3F8/4, так и вариантов клиентов несколько...заточенных под определенную задачу.
Сейчас под самого легкого клиента мне удалось написать клиент/сервер приложение(SDK). Просто сама структура клиента понятна(он формирует определенный файл — запрос и посылает на какой нибудь из концентраторов(концентраторы они владеют кое какой инфой)).На концентраторе крутится сервер который имеет доступ к прогр-ме конц-ра через общую память(ДЛЛ предоставленная разработчиками). Но этих клиентов 20-30%, с тяжелыми клиентами сложнее они формируют хренову тучу файлов запросов, скажу также что в основе этих легких клиентов лежит тот же легкий клиент, через который и происходит отсыл инфы. Переписать тяжелых клиентов практически не возможно из-за специфики(очччень навороченный АРМ), да и ежемесячное обновление справочников... Формирование которых происходит на самом пике пирамиды.
С протоколом передачи используемым в данной сети мне разобраться не получилось...Како то он хитрый. Последовательность передачи одного и того же файла(блока байт) разная, то он по байтно пуляет, то блоками разного размера.
С разработчиками связаться не получилось(не понятно и софт вроде обновляется(правда все под ДОС)).
Начал копать в сторону ДДК98...Ё маЁ!!! Там все под АСМ? С ДДК_НТ и т.д. все в принципе как то понятно. Вообще я думал какимто образом эмулировать КОМ порты на концетраторах, на клиентах можно было бы заменить стандартный драйвер своим с функцией редиректа на сокет.
VAB>сейчас я вижу что есть обычные клиенты с 1-2мя компортами и много концентраторов на каждом из которых есть плата расширения дающая 8-24 компорта. Которые в свою очередь куда-то уходят и именно на том конце хочется получать клиентский траффик по TCP? (А как он сейчас получается то? И кем?)
Верно. Эта систма запросов, клиенты формируют и запрашивают "базу данных".
VAB>но в такой ситуации на клиентах ставится указанная прога которая редиректит в сеть локальные клиентские компорты, а в сети (на том конце) следует уже похоже делать сервер который сделает концентраторы просто лишним звеном в цепи: проблема в том что предложенная прога похоже принимает "на том конце" траффик и требует сложить его обратно в какой-то компорт?
Нет, без концентраторов нельзя, каждый из них является носителем какойто инфы. Как я писал выше в протоколе разовраться у меня не получилос(я уже думал об этом, можно было бы через ту же ДДЛ).
VAB>отмечу что по этой цитате впечатление что речь о клиентах (слова ВСЕ и КАЖДОЙ не позволяют думать как о серверах)
Извиняюсь, что ввел в заблуждение
А>>8-24 порта относится именно к концентраторам.Я хотел бы полностью избавиться от МОКС... Ставить на концентраторах НТ — не катит их много, да ресурс у нех слаб(есть и IBM 166/32/..) их ф-ция типа хаба.
VAB>все таки неясно, а куда с концентраторов указанные МОКСы траффик заруливают?
Хоть куда.Концентраторы так же формируют что то вроде таблицы маршрутизации. У каждого клиента, так же как и концентратора есть свой "АЙПи", он называется автоответ. В файле запросе все и прописывается источник, назначение, и тд.
ибо сейчас поразмыслив мне уже не кажется драйвер обязательным условием, скорее наоборот обойтись обычным win32 сервисом к слову будет самым оптимальным вариантом, хватит пожалуй и Platform SDK: Device I/O Communications Functions),
Можете вот здесь растолковать
стало более понятно, надо подумать.
попробуйте пока в форуме asm собрать идеиАвтор: Valery A. Boronin
Дата: 06.11.05
, может быть там что посоветует кто?
А>А>ибо сейчас поразмыслив мне уже не кажется драйвер обязательным условием, скорее наоборот обойтись обычным win32 сервисом к слову будет самым оптимальным вариантом, хватит пожалуй и Platform SDK: Device I/O Communications Functions),
А>Можете вот здесь растолковать
это было написано когда я еще заблуждался
там имелось ввиду что программа типа ip->com наверное не требует драверов, достаточно пользоваться тем что дано в ссылке
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
А>Начал копать в сторону ДДК98...Ё маЁ!!! Там все под АСМ? С ДДК_НТ и т.д. все в принципе как то понятно. Вообще я думал какимто образом эмулировать КОМ порты на концетраторах, на клиентах можно было бы заменить стандартный драйвер своим с функцией редиректа на сокет.
Т.е. вы хотите вместо serial использовать для связи с хабами TCP\IP? Если да, и сами хабы предоставляют ком порты, которые видны из диспетчера устройств, тогда можно использовать нечто вроде
этого (Почему то у меня есть ощущение, что я видел и бесплатный аналог с виртуальными ком портами). Эффективнее, кстати, сделать вряд ли получится, поскольку там используется для редиректа в TCP интерфейс TDI. Впрочем, непонятно, что это даст кроме возможности удаленного выноса клиента. Производительность все равно будет ограничена производительностью serial интерфейса хаба, хотя... тут надо пробовать.
Если виртуальные ком порты на клиенте действительно нужны только для дос приложений, то все несколько проще. В случае winnt существует интерфейс VDD, который полностью user-mode (фактически просто обычная dll, подробнее в DDK в секции writing a VDD). C 9х линейкой сложнее — там виртуальные устройства суть VxD файлы, впрочем, в DDK есть и это.
Другое предложение — если есть исходники клиентских приложений, почему бы собственно не заменить всю работу с ком портом оберточными вызовами, которые будут работать с сокетами, вроде как в 9х сокетных интерфейс для ДОС приложений вполне поддерживается, судя по
http://support.microsoft.com/default.aspx?scid=kb;en-us;151210. Это получится в разы проще, нежели писать драйвер виртуального ком порта.
Здравствуйте, Аноним, Вы писали:
G>>http://www.tacticalsoftware.com/site/html/products/product-guide.htm
А>Блин, платная штука...А денег у конторы нЭт
Ну, нехороших советов давать не буду
G>>http://www.pcmicro.com/tcp-com/
А>ссылка не открывается
Открывается вроде. Но она тоже платная.
Здравствуйте, Andrew S, Вы писали:
AS>Т.е. вы хотите вместо serial использовать для связи с хабами TCP\IP? Если да, и сами хабы предоставляют ком порты, которые видны из диспетчера устройств, тогда можно использовать нечто вроде этого (Почему то у меня есть ощущение, что я видел и бесплатный аналог с виртуальными ком портами). Эффективнее, кстати, сделать вряд ли получится, поскольку там используется для редиректа в TCP интерфейс TDI. Впрочем, непонятно, что это даст кроме возможности удаленного выноса клиента. Производительность все равно будет ограничена производительностью serial интерфейса хаба, хотя... тут надо пробовать.
Как я писал концентраторы, не просто хабы, а еще и "база данных", "маршрутизатор". Достижения по увелечению скорости не нужны, нужно прийти к единому стандарту Ethernet. А не прокладывать 2 паралельные сетки. Так же проблемы с Security... AD, авторизация и т.д. Вообщем "com"
проблем с попытками догнать прогресс
AS>Если виртуальные ком порты на клиенте действительно нужны только для дос приложений, то все несколько проще. В случае winnt существует интерфейс VDD, который полностью user-mode (фактически просто обычная dll, подробнее в DDK в секции writing a VDD). C 9х линейкой сложнее — там виртуальные устройства суть VxD файлы, впрочем, в DDK есть и это.
Да, я и говорю c winnt все ясно, но ресурс машин-концентраторов слаб... Тут тупик
AS>Другое предложение — если есть исходники клиентских приложений, почему бы собственно не заменить всю работу с ком портом оберточными вызовами, которые будут работать с сокетами, вроде как в 9х сокетных интерфейс для ДОС приложений вполне поддерживается, судя по http://support.microsoft.com/default.aspx?scid=kb;en-us;151210. Это получится в разы проще, нежели писать драйвер виртуального ком порта.
Если бы, я Вас не мучил...
Здравствуйте, Andrew S, Вы писали:
А>>Блин, платная штука...А денег у конторы нЭт
AS>http://www.hw-group.com/products/hw_vsp/index_en.html
AS>Оно?
Я тоже дня 2 назад нарвался на данную прогу, но...
Мне кажется не подходит. Во первых она не работает с ДОС приложениями, во-вторых не совсем понятно как можно организовать пул виртуальных портов на концентраторе...
З.Ы. У программы еще замечен один минус — очень тормозит систему, что пару раз приводило к зависанию.
