Привет всем. Меня интересует некоторые сведения о показателях применения технологии COM Internet Services (CIS) — если кто нибудь работал с этим фичером, отзовитесь.
Прежде всего напомним о чем идеть речь. CIS являет собой новую реализацию DCOM протокола для Web. Как известно, применение традиционного DCOM в глобальной сети значительно затрудненно по причине сетевой имплементации оного. Как известно, для комуникации этот протокол использует TCP/IP — 135 порт занят под SCM, через него СОМ библиотеки на разных хостах разговаривают и оповещают друг друга о номерах сокетов удаленных обьектов и многое другое. Во вторых, и самое проблемное, на мой взгляд, СОМ библиотека для соединения каждого объекта с сетью строит для него персональный сокет в диапазоне портов от 1024 до конца. Таким образом, если связь происходит через FireWall, весь этот диапазон (плюс порт 135) должен быть открыт. Согласитесь, огромнейшая дыра образуется в системе как сервера так и клиентов. Есть средства настройки СОМ библиотеки на хосте, которая позволяет ограничить этот диапазон, но в любом случае дыра не позволительна. Кроме того огромные проблемы возникают при подключении клиента через прокси сервер к интернету. Все эти проблемы, как обещалось, решает новая имплементация DCOM — CIS, который основан на Tunneling TCP. Он позволяет, насколько я понял создавать коммуникации между клиентом и сервером только посредством 80 порта — т.е. все обьекты будут сидеть на одном порте, а взаимодействие строится над HTTP посылами, и со стороны сервера IIS (кстати только этот Веб сервер реализует эти вещи), встречая опсыл от CIS, пропускает его ниже, и один из ISAPI фильтров диспечеризирует его к конкретному обьекту. Таким образом, прокси сервер, встречая подобный запрос по 80 порту, рассматривает его как обычный HTTP request и пересылает на сторону Веб сервера, не подозревая что в теле запроса находится подзапрос для фильтра. Тоже самое происходит с ответами. Хотелось бы получить сведения о производительности данной имплементации.
Спасибо, Batiskaf.
Will I live tomorrow? Well I just can't say
But I know for sure — I don't live today.
Jimi Hendrix.
Здравствуйте Batiskaf, Вы писали:
B>Хотелось бы получить сведения о производительности данной имплементации.
А какая разница? Интернет не 100 мегобитка, работать быстрее не будет. :)
Сам подход уже испытанный, во асяких там RDS'ах и Remote Scripting, SOAP тоже на том же принципе сделан, так что можно особо не переживать, брать и пользоваться. Кроме как запихнуть данные в тело HTTP запроса лучше ничего не придумаешь.
Мерять же производительность в данном случае скорее всего просто не имеет смысла.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте IT, Вы писали:
IT>Здравствуйте Batiskaf, Вы писали:
B>>Хотелось бы получить сведения о производительности данной имплементации.
IT>А какая разница? Интернет не 100 мегобитка, работать быстрее не будет. :) IT>Сам подход уже испытанный, во асяких там RDS'ах и Remote Scripting, SOAP тоже на том же принципе сделан, так что можно особо не переживать, брать и пользоваться. Кроме как запихнуть данные в тело HTTP запроса лучше ничего не придумаешь. IT>Мерять же производительность в данном случае скорее всего просто не имеет смысла.
Не, ну, почему? Если человек измерит, думаю rsdn без проблем опубликует эти результаты!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.