Задача:
Сделать серверное приложение, которое время от времени по каналу TCP/IP обменивается некой информацией с клиентами по инициативе самих клиентов. Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. Там же возможность работы с базой данных (добавить там, удалить, изменить).
Подскажите пожалуйста как мне организовать это приложение? Т.е. может здесь нужно сделать службу? Или приложение, которое будет висеть в трейе?
Т.к. вопрос объемный лучше будет наверно, если вы посоветуете мне какую-нибудь книгу или ссылку.
А обязательно TCP/IP? Может лучше вообще сделать Web-приложение? Пусть юзеры что надо аплоадят эксплорером, веб-интерфейс прикрутить просто, и с БД работать тоже несложно.
Здравствуйте, Amor, Вы писали:
A>Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI.
Зачем? Локально клиент тоже можт быть запущен. Вопрос только, какие клиенты будут.
A>Т.е. может здесь нужно сделать службу?
Лучше так, к тому же получишь фактически нахаляву возможность частичного удаленного управления.
A>Или приложение, которое будет висеть в трейе?
А вот это не надо. Вообще без GUI лучше обойтись.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Amor, Вы писали:
A>>Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. V>Зачем? Локально клиент тоже можт быть запущен. Вопрос только, какие клиенты будут.
Здесь ресь не о клиенте идет. GUI для сервера.
A>>Т.е. может здесь нужно сделать службу? V>Лучше так, к тому же получишь фактически нахаляву возможность частичного удаленного управления.
A>>Или приложение, которое будет висеть в трейе? V>А вот это не надо. Вообще без GUI лучше обойтись.
GUI нужно, для выполнения пользователем других действий (там же — работа с БД)
Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI.
Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Amor, Вы писали:
G>А обязательно TCP/IP? Может лучше вообще сделать Web-приложение? Пусть юзеры что надо аплоадят эксплорером, веб-интерфейс прикрутить просто, и с БД работать тоже несложно.
Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия человека.
Здравствуйте, Amor, Вы писали:
A>Здесь ресь не о клиенте идет. GUI для сервера.
не является нужным.
A>GUI нужно, для выполнения пользователем других действий (там же — работа с БД) A>Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI.
А почему он не может это действия сделать через клиента?
И вообще, что за действия на сервере требуют GUI? Ибо для подключения к базе GUI не надо.
A>Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия >человека.
вы слишком мало задали условий чтобы выдать какие-то рекомендации
Есть же множество проверенных промышленных решений для архитектуры клиент-сервер,
выбор которых зависит от множества факторов
(ОС, язык/среда разработки, необходимость стыковки с существующим ПО)
начните с детальной постановки задачи, возможно решение придет само собой
Здравствуйте, Amor, Вы писали:
A>Привет всем!!!
A>Задача: A>Сделать серверное приложение, которое время от времени по каналу TCP/IP обменивается некой информацией с клиентами по инициативе самих клиентов. Кроме того программа должна иметь возможность выполнять дополнительные действия связанные с ее деятельностью, т.е. здесь должен быть GUI. Там же возможность работы с базой данных (добавить там, удалить, изменить).
A>Подскажите пожалуйста как мне организовать это приложение? Т.е. может здесь нужно сделать службу? Или приложение, которое будет висеть в трейе?
A>Т.к. вопрос объемный лучше будет наверно, если вы посоветуете мне какую-нибудь книгу или ссылку.
A>Спасибо заранее.
На C# элементарно написать сервисное приложение. Как механизм обмена данными выбрать Remoting. С СОМ+ лучше не связываться и веб-сервисы мне тоже не нравятся, а вот ремоутинг можно будет даже в инет вытащить и использовать как веб сервисы. Т.е. ремоутинг сможет работать в интранете обмениваяюсь данными в бинарном виде и в инете обмениваясь ХМЛ-ом без написания каких-либо доп. оберток.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Amor, Вы писали:
A>>Здесь ресь не о клиенте идет. GUI для сервера. V>не является нужным.
A>>GUI нужно, для выполнения пользователем других действий (там же — работа с БД) A>>Т.е. программа постоянно работает с клиентами, а когда пользователю моего приложения понадобиться сделать эти действия — он "запускает" GUI. V>А почему он не может это действия сделать через клиента? V>И вообще, что за действия на сервере требуют GUI? Ибо для подключения к базе GUI не надо.
Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так?
K>На C# элементарно написать сервисное приложение. Как механизм обмена данными выбрать Remoting. С СОМ+ лучше не связываться и веб-сервисы мне тоже не нравятся, а вот ремоутинг можно будет даже в инет вытащить и использовать как веб сервисы. Т.е. ремоутинг сможет работать в интранете обмениваяюсь данными в бинарном виде и в инете обмениваясь ХМЛ-ом без написания каких-либо доп. оберток.
*** А что это за зверь такой Remoting? Может посоветуйте что и где почитать о взаимодействии различных серверов между собой, особенно что нового появилось в этой области.
Сейчас я разрабатываю сервера приложений (например игровые сервера) на С++ и сокетах, все взаимодействие в форме XML, что достаточно трудоемко. Интересно как это делают другие... Было бы интересно поделиться опытом.
Здравствуйте, Amor, Вы писали:
A>Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так?
возьми любое серверное приложение — это сервисы безGUIвые. Все управление (GUI или командная строка) через отдельное приложение
примеры:
IIS, MS SQL сервер, Exchange
Oracle 8i/9i
рассмотри вариант выключения/включения питания (когда нет оператора)
Здравствуйте, SCS, Вы писали:
SCS>Здравствуйте, Amor, Вы писали:
A>>Схему так можно описать: КЛИЕНТ-СЕРВЕР-ПОЛЬЗОВАТЕЛЬ. Клиент время от времени отправляет серверу информацию о своей деятельности. Сервер там ему что-то отвечает. Пользователь же должен выполнять некие действия. Можно конечно, это GUI вынести вообще в отдельное приложение. Не знаю грамотно ли так делать? Делают ли так? SCS>возьми любое серверное приложение — это сервисы безGUIвые. Все управление (GUI или командная строка) через отдельное приложение
SCS>примеры: SCS>IIS, MS SQL сервер, Exchange SCS>Oracle 8i/9i
SCS>рассмотри вариант выключения/включения питания (когда нет оператора)
Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно.
Здравствуйте, Amor, Вы писали: A>Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно.
Не обязательно через ControlService(). Через это управляют только "тпру" да "поехали" — через Control Panel, MMC, FAR Plugin и еще туеву хучу всего. Просто твое приложение как-то коннектится к службе и общается с ней. Например, для MS SQL есть свои протоколы подключения для выполнения SQL команд. И все управление сервером при помощи них и происходит.
... << RSDN@Home 1.0 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Amor, Вы писали: A>>Т.е. можно сделать так: написать службу, которая запускается при запуске системы, взаимодействует с клентами, обращается к БД и проч. И есть отдельное приложение, которое выполняет вот те самые "загадочные" действия и управляет службой через ControlService() возможно даже удаленно. S>Не обязательно через ControlService(). Через это управляют только "тпру" да "поехали" — через Control Panel, MMC, FAR Plugin и еще туеву хучу всего. Просто твое приложение как-то коннектится к службе и общается с ней. Например, для MS SQL есть свои протоколы подключения для выполнения SQL команд. И все управление сервером при помощи них и происходит.
Чего-чего-то я не понял.....
Что значит тпру-да-поехали?
Как надо?
Управление службой + выполнение определенных действий = вот что мне надо сделать
Здравствуйте, Amor, Вы писали:
A>Чего-чего-то я не понял..... A> A>Что значит тпру-да-поехали?
Значит через ControlService службу можно остановить и запустить. Все. A>Как надо? A>Управление службой + выполнение определенных действий = вот что мне надо сделать
Вынудить службу на "выполнение определенных действий" придется по своему коммуникационному каналу. На выбор:
— Перезапись конфигурационного файла в условленном месте
— Named Pipes
— TCP/IP
— ... гуру дополнят.
... << RSDN@Home 1.0 beta 3 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Amor, Вы писали:
A>>Чего-чего-то я не понял..... A>> A>>Что значит тпру-да-поехали? S>Значит через ControlService службу можно остановить и запустить. Все.
Но можно ведь передавать в ControlService() пользовательские коды. А не только SERVICE_CONTROL_XXX.
Здравствуйте, Amor, Вы писали:
A>Но можно ведь передавать в ControlService() пользовательские коды. А не только SERVICE_CONTROL_XXX.
числа 128-255. даже сточку не передать. очень ограничено.
делай по Remoting (если .Net), NamedPipe, TCP/IP, COM+
A>>Ну здесь не пользователи (люди) пользуются услугами сервера. А клиентские программы сами, без участия >человека.
A>вы слишком мало задали условий чтобы выдать какие-то рекомендации A>Есть же множество проверенных промышленных решений для архитектуры клиент-сервер, A>выбор которых зависит от множества факторов A>(ОС, язык/среда разработки, необходимость стыковки с существующим ПО) A>начните с детальной постановки задачи, возможно решение придет само собой
A>>(ОС, язык/среда разработки, необходимость стыковки с существующим ПО) A>>начните с детальной постановки задачи, возможно решение придет само собой
A>ОС — WindowsNT A>язык/среда — Visual C++ 6.0
как один из жизнеспособных вариантов — ISAPI, http, xml.
мы такое делали, сервер управлялся через сервисное приложение имеющее GUI и
запускающее/останавливающее IIS с помощью SCM API (описано в книге Рихтера и Кларка)
Лично я, сервер в подобном проекте реализовал как обычное приложение, с GUI. Прячется в трей, где и ожидает запрсов от клиентов Через этот самый GUI добавляются/удаляются/изменяются клиенты (ну и ещё кой-какие действия). Но. Этот сервак работает с сеткой, => необходимо залогиниться => службу делать смысла нет. Иначе лучше было бы службой (в основном из-за выключения/включения). Тогда клиентское (относительно к службе) приложение можно размещать где угодно, что удобно.
Здравствуйте, Gomes, Вы писали:
G>Прячется в трей, где и ожидает запрсов от клиентов
Ага, необходим трей, следовательно, и логин.
G>Этот сервак работает с сеткой, => необходимо залогиниться => службу делать смысла нет.
Пошукай на форуме WinAPI, там есть решение, AFAIR даже на первой странице. И логиниться тоже не надо.
Здравствуйте, vasketsov, Вы писали:
v>Пошукай на форуме WinAPI, там есть решение, AFAIR даже на первой странице. И логиниться тоже не надо.
Всё же, наверное, надо. Работает с НетВаревскими дисками. Да и мне это не критично.
Здравствуйте, Avdos, Вы писали:
A>*** А что это за зверь такой Remoting? Может посоветуйте что и где почитать о взаимодействии различных серверов между собой, особенно что нового появилось в этой области. A>Сейчас я разрабатываю сервера приложений (например игровые сервера) на С++ и сокетах, все взаимодействие в форме XML, что достаточно трудоемко. Интересно как это делают другие... Было бы интересно поделиться опытом.
Remoting механизм коммуникации в ДотНет, читать в MSDN, может и здесь есть статья.
Здравствуйте, Gomes, Вы писали:
G>Лично я, сервер в подобном проекте реализовал как обычное приложение, с GUI. Прячется в трей, где и ожидает запрсов от клиентов Через этот самый GUI добавляются/удаляются/изменяются клиенты (ну и ещё кой-какие действия). Но. Этот сервак работает с сеткой, => необходимо залогиниться => службу делать смысла нет. Иначе лучше было бы службой (в основном из-за выключения/включения). Тогда клиентское (относительно к службе) приложение можно размещать где угодно, что удобно.
Разясни пожалуйста вот от сюда:
... необходимо залогиниться => службу делать смысла нет. Иначе лучше было бы службой (в основном из-за выключения/включения). Тогда клиентское (относительно к службе) приложение можно размещать где угодно, что удобно.
Здравствуйте, vasketsov, Вы писали:
V>Здравствуйте, Gomes, Вы писали:
G>>Прячется в трей, где и ожидает запрсов от клиентов V>Ага, необходим трей, следовательно, и логин.
G>>Этот сервак работает с сеткой, => необходимо залогиниться => службу делать смысла нет. V>Пошукай на форуме WinAPI, там есть решение, AFAIR даже на первой странице. И логиниться тоже не надо.
А че-эт тако та, AFAIR???
И что искать надо? Форум он большой...
Здравствуйте, Amor, Вы писали:
A>А че-эт тако та, AFAIR???
As Far As I Remember
A>И что искать надо? Форум он большой...
Читай все, все полезно.
Вот это сотоварищи: http://rsdn.ru/forum/Message.aspx?mid=168078
Здравствуйте, Amor, Вы писали:
A>Разясни пожалуйста вот от сюда: A>[q] A>... необходимо залогиниться => службу делать смысла нет. Иначе лучше было бы службой (в основном из-за выключения/включения). Тогда клиентское (относительно к службе) приложение можно размещать где угодно, что удобно.
В моём случае не было смысла усложнять службой. Поставил сервака в автозагрузку и ладно. А если надо чтобы в случае чего (выключение/включение) всё работало, тогда лучше службой. И приложение, которое будет управлять службой и БД, может находиться на другой машине к примеру. Ничего нового не сказал?
Спрашивай поконкретней.
Здравствуйте, Gomes, Вы писали:
G>Здравствуйте, Amor, Вы писали:
A>>Разясни пожалуйста вот от сюда: A>>
A>>..необходимо залогиниться => службу делать смысла нет
. Иначе лучше было бы службой (в основном из-за выключения/включения). Тогда клиентское (относительно к службе) приложение можно размещать где угодно, что удобно.
G>В моём случае не было смысла усложнять службой. Поставил сервака в автозагрузку и ладно. А если надо чтобы в случае чего (выключение/включение) всё работало, тогда лучше службой. И приложение, которое будет управлять службой и БД, может находиться на другой машине к примеру. Ничего нового не сказал?
G>Спрашивай поконкретней.
Если конкретней.
Вот что это значит?
[q]
необходимо залогиниться => службу делать смысла нет
Здравствуйте, Amor, Вы писали:
A>Если конкретней. A>Вот что это значит? A>необходимо залогиниться => службу делать смысла нет
Ну я ж сказал: в автозагрузку кинул, сервак и запустился.
A>И выключение/включение чего имеется ввиду?
Машины ясен пень Вот электричество кончится — тачка выключится, когда включится залогиниться будет некому (всякое бывает), а служба запустится и будет обрабатывать клиентов.
Здравствуйте, Gomes, Вы писали:
G>Здравствуйте, Amor, Вы писали:
A>>Если конкретней. A>>Вот что это значит? A>>необходимо залогиниться => службу делать смысла нет
G>Ну я ж сказал: в автозагрузку кинул, сервак и запустился.
G> A>>И выключение/включение чего имеется ввиду?
G>Машины ясен пень Вот электричество кончится — тачка выключится, когда включится залогиниться будет некому (всякое бывает), а служба запустится и будет обрабатывать клиентов.
G>
Можно субмитить данные программно, в виде XML.
действия и управляет службой через ControlService() возможно даже удаленно.
