Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных
и сами изменённые данные, а также принимать то же самое от клиентов...
Клиенты в Интернете, кто-то за проксёй, кто-то нет.
На чём писать передачу данных? Всё это ориентировано на W2k.
Здравствуйте DNS, Вы писали:
DNS>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
DNS>На чём писать передачу данных? Всё это ориентировано на W2k.
Быстрее и удобнее всего на дотнете. Самый компатибельный вариант — COM+.
Здравствуйте DNS, Вы писали:
AVK>>Быстрее и удобнее всего на дотнете. Самый компатибельный вариант — COM+.
DNS>Пасиба, а сэмплов или обзорных статей не подскажете ли местонахждение?
По чему? По DCOM их море в инете. По ремоутингу будет небольшая статья в только что вышедшем RSDN Mag #1
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте DNS, Вы писали:
DNS>>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
DNS>>На чём писать передачу данных? Всё это ориентировано на W2k.
AVK>Быстрее и удобнее всего на дотнете. Самый компатибельный вариант — COM+.
Согласен, на .Net + Remoting это достаточно удобно, вопрос только как это сделать с проксей соеденить
Здравствуйте Ursus, Вы писали:
AVK>>Быстрее и удобнее всего на дотнете. Самый компатибельный вариант — COM+.
U>Согласен, на .Net + Remoting это достаточно удобно, вопрос только как это сделать с проксей соеденить
Без проблем. Используй HttpChannel и не открывай на клиенте двунаправленный канал.
Здравствуйте DNS, Вы писали: DNS>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
Я бы использовал COM (COM+) и SOAP в качестве транспорта. Медленно, зато отлично работает через всякие FireWall'ы Proxy'и
Здравствуйте AndrewVK, Вы писали:
AVK>Здравствуйте DNS, Вы писали:
DNS>>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
DNS>>На чём писать передачу данных? Всё это ориентировано на W2k.
AVK>Быстрее и удобнее всего на дотнете. Самый компатибельный вариант — COM+.
А COM+ поддерживает клиентов не в локальной сети? А какие тогда особенности установки клиентских приложений?
Здравствуйте DNS, Вы писали:
DNS>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
самые проблемы это отсылать уведомления клиентам
потому что они входящих коннектов естественно не принимают (файрволы, прокси и прочее)
вот тут встает вопрос как это сделать?
два варианта:
1 — клиент держит постоянный коннект с сервером и по нему сервер оповещает клиента
2 — клиент заходит на сервер с какой то частотой
в первом варианте только самому реализовывать протокол на чистых сокетах
Здравствуйте Banch, Вы писали:
B>самые проблемы это отсылать уведомления клиентам B>потому что они входящих коннектов естественно не принимают (файрволы, прокси и прочее) B>вот тут встает вопрос как это сделать? B>два варианта: B>1 — клиент держит постоянный коннект с сервером и по нему сервер оповещает клиента B>2 — клиент заходит на сервер с какой то частотой
B>в первом варианте только самому реализовывать протокол на чистых сокетах
Грррм.,.... А как же поддержка событий в COM+, там подписки всякие и издатели,
разве они не для этого сделаны?!
Здравствуйте Banch, Вы писали:
B>вся фишка в подписке: как достучаться до клиента через файрвол? B>как бы круто технология не называлась, но она не сможет через него прорваться
Ну, если транспорт HTTP, то наверное прорваться можно...
Надежда только что 80-ый порт не закрыли
B>если оперативность не важна — можно по мылу оповещать
В том-то и дело что важна.
Да и чем мыло отличается от постоянных запросов к серверу о изменениях?
Здравствуйте DNS, Вы писали:
B>>вся фишка в подписке: как достучаться до клиента через файрвол? B>>как бы круто технология не называлась, но она не сможет через него прорваться
DNS>Ну, если транспорт HTTP, то наверное прорваться можно... DNS>Надежда только что 80-ый порт не закрыли
ага, представляю, приходит юзер к админу и просит проковырять в файрволе дырку, чтоб кто-то со стороны мог на его, юзерскую, тачку запросы слать
вот админ то посмеется
B>>если оперативность не важна — можно по мылу оповещать
DNS>В том-то и дело что важна. DNS>Да и чем мыло отличается от постоянных запросов к серверу о изменениях?
можно на приход почты скрипт повесить, который будет сразу клиента дергать
конечно надежность хромает (типо мыло не дойдет или зависнит оно где-нть на пару часов)
удобней клиенту держать постоянный коннект с сервером — по которому и будет сервер гнать данные и/или события клиенту
Здравствуйте Banch, Вы писали:
B>ага, представляю, приходит юзер к админу и просит проковырять в файрволе дырку, чтоб кто-то со стороны мог на его, юзерскую, тачку запросы слать B>вот админ то посмеется
Да, можно коннект постоянный держать, просто очень бы хотелось абстрагироваться от сокетов
любыми возможными способами.
Вот и ищу что подойдёт лучше всего, не найду — будут сокеты. Но, думаю, найду, не может быть чтобы
это никого раньше не беспокоило...
Здравствуйте DNS, Вы писали:
DNS>Здравствуйте Banch, Вы писали:
B>>вся фишка в подписке: как достучаться до клиента через файрвол? B>>как бы круто технология не называлась, но она не сможет через него прорваться
SMTP через что угодно пролезет DNS>Ну, если транспорт HTTP, то наверное прорваться можно... DNS>Надежда только что 80-ый порт не закрыли
B>>если оперативность не важна — можно по мылу оповещать
DNS>В том-то и дело что важна. DNS>Да и чем мыло отличается от постоянных запросов к серверу о изменениях?
В том, что сервер сам рассылает изменения. В случае с .NET вообще просто: клиент (или сервер) может выбрать наиболее удобный транспорт в зависимости от конфигурации сети (TCP, HTTP, SMTP/POP3)
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>В том, что сервер сам рассылает изменения. В случае с .NET вообще просто: клиент (или сервер) может выбрать наиболее удобный транспорт в зависимости от конфигурации сети (TCP, HTTP, SMTP/POP3)
А не подскажете, как лучше всего работать с POP3? Есть ли что-то наподобие System.Web.Mail.SmtpMail для протокола POP3?
DNS>На чём бы мне написать следующую штуку: DNS>Есть серверной приложение, которое должно рассылать клиентам уведомления об изменении данных DNS>и сами изменённые данные, а также принимать то же самое от клиентов... DNS>Клиенты в Интернете, кто-то за проксёй, кто-то нет.
а на сколько акрутально быстродействие (точнее время отклика)?
(можно мочкануть через почтовый сервер)
DNS>На чём писать передачу данных? Всё это ориентировано на W2k.
имхо — всякие прокси шлюзы etc — нужен текстовый формат, тобишь — xml => .Net,
(потому что там до ума доведено) но существует масса нативных решений..
в лбом случае — http(s) + xml
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
"Sulik" <16365@news.rsdn.ru> wrote in message news:431881@news.rsdn.ru... > Здравствуйте, TK, Вы писали: > > TK>В том, что сервер сам рассылает изменения. В случае с .NET вообще просто: клиент (или сервер) может выбрать наиболее удобный транспорт в зависимости от конфигурации сети (TCP, HTTP, SMTP/POP3) > > А не подскажете, как лучше всего работать с POP3? Есть ли что-то наподобие System.Web.Mail.SmtpMail для протокола POP3?
