Apache сервер. Как запустить exe?
Просто я к тому, что сервер находится на бесплатном хостинге (не важно каком, а то сочтете за рекламу).
кроме того - читаем спецификацию CGI
Apache общается с клиентами (браузерами например) через протокол HTTP. Или твой чат тоже делает запрос к веб серверу (а не твоему серверу написанному на c++) по протоколу HTTP, передает нужные значения. А веб сервер вызывает твой сервер (который получается не совсем сервер) и дает ему эти значения. А потом твой сервер генерит ответ, дает его web-серверу, и тот шлет его тебе обратно по HTTP протоколу? Если нет то никакой Apache тут ни к чему и совершенно не нужен. =)
aks, я честно говоря запутался в твоем тексте, но по ходу идею понял. Ты все равно ссылаешь меня почитать ссылки squirL'a. Что я собственно и делаю ;)
Спасибо за помощь.
Если есть сетевое клиент-серверное приложение какое-то, подразумевается вот что:
Есть запущенный и работающий сервер. Причем естественно он должен или не зависить от платформы, или его исполняемый файл собран под ту ОС, которая стоит на сервере. (Тоесть .exe имеет смысл делать только если на сервере стоит винда) Сервер (программа) постоянно работает и ждет сетевых подключений. Клиенты (те программы которые выполняются на стороне пользователя) подключаются напрямую к серверу по указанному адрессу и порту (открывают сокет) и напрямую общаются через этот сокет - шлют данные как хотят по своему собственному протоколу.
Теперь если есть HTTP сервер например Apache. Это такой же сервер как и в первом случае. К нему так же подлючаются клиенты (обычно браузеры) по указанному адрессу и порту (обычно этот порт 80, поэтому его не пишут) и начинают общаться по стандартизованному протоколу HTTP, который кстати далеко не идеальный и приспособлен впринципе то как раз для доставки web страниц.
Основной его приципы - например клиент (браузер) посылает HTTP запрос в котором указывает URL который хочет загрузить. Сервер шлет ему HTTP ответ c нужным документом. Если нужен результат выполнения CGI программы (что по сути уже является заплаткой над несовершенным протоколом) то в HTTP запросе указывается эта программа, и данне которые ей надо передать. Сервер запускает программу - она данные обрабатывает, и генерит сообщение (например html страничку) - отдает ее обратно серверу. Сервер же шлет ее клиенту (браузеру). ну это так в двух словах.
Тоесть Apache нужен если все общение построенно через HTTP запросы при посредничестве web-сервера, что само по себу странно и не эффективно - так никто не делает, потому я и усомнился. Если же чат устроен так как я написал сначала, тоесть клиенты и сервер напрямую общаются друг с другом - Apache тут ни каким боком не даже нежен.
Если написанное вами приложение является CGI-совместимым, то всё правильно - его нужно бросить в cgi-bin и запускать его оттуда. Но в httpd.conf нужно добавить поддержку exe как cgi.
Однако выложить что-либо на хостинге, тем более на бесплатном. Хостинги как правило не Windows. А под виндовс, да ещё в качестве CGI-приложения никак не получится.
Это еще почему не получится? )
А вобще судя по ответом автора, мне так кажется что там всеже обычный сетевой чат безо всякого web. Просто ассоциация видимо въелась, раз на хостинге размещать - значит апач и Cgi =)
а я то, дурень, думал, что спецификация CGI ни от ОС, ни от языка реализации не зависит...
aks
а почему чат как CGI не эффективен?
и почему вы называете CGI "заплаткой" надо несовершенным протоколом?
Не совсем так. Просто нет смысла организовывать такой чат, где клиент и сервер (всеже серверная программа была названна сервером) не привязанные к web и при этом исспользуют непонятно для какой цели web-сервер в качестве посредника подстраиваясь на исспользование созданного для других целей совсем протокола HTTP.
Такие клиенты как web-браузеры - они вынужденны подстраиваться под эту модель, так как для web страниц это стандарт и монополия, да и все же он для них более логичен. Для двух простых сетевых приложений логичней открыть просто прямое соединение безо всяких посредников. Ну я к тому, что каждый инструмент для своих целей лучше исспользовать. Представте себе SSH протокол реализованный через HTTPS запросы =)
Ну все же HTTP изначально был создан ведь просто для передачи нужных документов по запросам (в первую очередь html страниц) так? Это потом уже когда появилась нужда в динамике и обратной связи от юзера к серверу добавили поддержку CGI. Потому и заплатка. Протокол не то чтобы не совершенный, просто изначально его рамки были несколько другии. Сейчас же потребности несколько возросли вот и исспользуются всевозможные надстройки и т.п. Ведь дешевле поддерживать, чем если бы создать принципиально новый протокол взамен того, на котором весь веб держится.
Ну а для конкретной задачи в конретной аппликухе всегда проще свой протокол исспользовать чам извращаться с HTTP, если требования у нее другие чем у подкачка документов с сайта.
Собственно тема то была созданна в другом разделе, и автор выразил непонимание моим словам - вот я и попытался чуть развернуто но и просто рассказать суть )
Прошу прощения у всех, кого ввёл в заблуждение! Запутался.
Имелось ввиду то, что несмотря на CGI-стандарт, который конечно же поддерживается одинаково на всех платформах, программа exe написанная по Win32 под ней одно только и будет запускаться. Exe есть exe несмотря на совместимость с CGI и на бесплатном хостинге оно работать не будет.
по первому вопросу - используя CGI приложение в качестве чата, программист избавляет себя от огромного количества рутины, которую за него выполнит веб сервер.
по второму. это не называется "заплатка". это называется разбиение на уровни :) есть простой протокол передачи гипертекста. достаточный для некоторых задач. если задачи усложняются, мы добавляем следующий уровень. все логично. а создавать новый протокол было бы не рационально. лучше много, но простых, чем одинЮ но раздутый и запутанный
Тут бы поспорил. Точно так же можно всринимать как наоборот рутину и адаптацию к HTTP протоколу, вместо простого чтения/записи нужных данных из сокета.
Создавть новый протокол конечно не рационально. Только чтото я сомневаюсь, что CGI создавался как логическое продуманное продолжение и надстройка HTTP. Все же он возник из необходимости сделать что то. А так для удаленного вызова бывют куда более удобные протоколы.
Опять же из-за невозможности поддерживать постоянную сесию начали создавть надстройку позволяющую ее эмулировать и т.п.