http запрос

Ага.

Unix socket.

А можно поподробнее, на пальцах, хотя бы сам смысл этой реализации, я мало что в этом смыслю.

Это такой интерфейс общения между программами и процессами, в рамках операционной системы.

Ну а если не ёрничать - задачу вы поставили как-то слишком некорректно.

запрос не открывая порт

в это время слушает порт

В речи это оксюморон, если мне не изменяет память.

Не, ну насколько я себе это представляю, программа, например курл, открывает порт, отправляет запрос, слушает порт дополучения ответа, получает ответ, считывает, выводит. Ну примерно. А мне надо чтобы одна прога отправила запрос (для этого ведь порт открывать не нужно? какими средствами отправляется запрос?) и ушла. А другая в это время слушала порт и получала ответ. Как это сделать.

Все это делается либо сокетами, либо пайпами, либо аргументами, либо открывая порт, слушая его и шля в него. Наверняка еще как-то, но я сам новичок и знаю только это

UPD: прочитал заголовок... Почему нельзя порт открывать? Отловить его сложно - пока будешь сканировать открытый на время передачи порт для небольшого количества данных, он уже сменится

Почему нельзя порт открывать

Потому что я пытаюсь реализовать что-то вроде сканера диапазона адресов на предмет существования. Я пытался реализовать с помошью Curl, но операционка не дает открыть сразу много экземпляров, приходится ограничиваться пятью (примерно) одновременно запущеных. Слишком медленно происходит сканирование.

сделать HTTP - запрос не открывая порт
одна программа отсылает запрос, а другая в это время слушает порт и принимает ответ

?? Это что-то из разряда "пожарить яичницу, не разбив яйца"?

если в рамках локального компьютера, то может и можно, однако и клиент и сервер должны быть «подключены» к unix сокету или вообще работать через pipe в консоле, однако в рамках tcp/ip это разумеется невозможно, поскольку чтобы началась передача чего-либо поверх tcp/udp надо для начала установить соединение.

сделать HTTP - запрос не открывая порт

вы наверно имели в виду «не открывая соединение», на серверной стороне порт всегда открыт и слушается веб сервером, на клиентской стороне порт никто не открывает, на клиентской стороне инициируется открытие соединения.

Почему нельзя порт открывать?

Если он не откроет порт, хрена с два он приконнектится ☺

Помню, когда-то давно я долго мучился, пытаясь понять, почему у меня мультикасты не проходят. Пока не почитал матчасть и не пофиксил iptables.

неважно, установлено соединение или нет, важно только удостовериться что сервер вернул 200

Чтобы сервер вернул тебе 200 (перед этим выслушав твой GET|POST|HEAD|Whatever), тебе нужно установить с ним соединение. Тисипи, как говорят французы.

важно только удостовериться что сервер вернул 200, дальше можно выйти

Тебе нужен HTTP метод HEAD. Это как GET, но сервер возвращает только заголовок, без тела.

Я так понимаю/предполагаю, что в низкоуровневом запросе к серверу есть информация, на какой порт отсылать ответ. И я подумал, что теоритически можно было бы построить такую модель: прога открывает порт, слушает его, а другая прога «знает», какой порт слушает первая и отсылает запрос к серверу с «просьбой» отослать ответ на этот самый порт, и не дожидаяь ответа посылает запрос следующему серверу, а та, первая, считывает ответы тем временем. Тут еще наверное, нужно как то организовывать очередь ответов, ведь они могут приходить асинхронно. Вот и спросил, возможна ли такая модель?

Чтобы сервер вернул тебе 200 (перед этим выслушав твой GET|POST|HEAD|Whatever), тебе нужно установить с ним соединение. Тисипи, как говорят французы.

Спасибо большое, значит это невозможно. Огромное спасибо, ответ прямо в точку.
и благодарю всех откликнувшихся!

А мне надо чтобы одна прога отправила запрос (для этого ведь порт открывать не нужно? какими средствами отправляется запрос?) и ушла.

Клиент тоже открывает порт на который он потом получает ответ сервера, просто этот порт берется рандомно.
До отправки http запроса у тебя еще происходит установление tcp соединение. Что то типо:
Клиент: привет
Сервер: привет
Клиент: походу соединение надежное, начинаю отправку данных
Клиент: http запрос.

В этом принципиальное отличие tcp от udp.

Потому что я пытаюсь реализовать что-то вроде сканера диапазона адресов на предмет существования. Я пытался реализовать с помошью Curl, но операционка не дает открыть сразу много экземпляров

Чем nmap не подходит? И с чего ты взял что ОС не дает открыть больше 5 курлов?
Если запросы не сложные, без всяких там shttp то забей на курл и делай через сокеты, http протокол это обычный текст, к веб серверу хоть по телнету можно подключаться.

Чем nmap не подходит

nmap я пробовал, мощная штука, но разве он может вернуть 200? он жа просто сканирует порты.

И с чего ты взял что ОС не дает открыть больше 5 курлов?

Я не помню там пять или больше, но на каком то количестве вылетала ошибка: слишком много открытых портов или процессов чтоли.

Если запросы не сложные, без всяких там shttp то забей на курл и делай через сокеты, http протокол это обычный текст, к веб серверу хоть по телнету можно подключаться.

Да наверное нужно смотреть в эту сторону. Я думаю что основные тормоза тут как раз в этом рукопожатии, неизбежное зло, пока ожидается ответ, процесс висит, а то бы можно было производить сканирование асинхронно с фантастической скоростью. Спасибо за ответ!

Только HEAD может возвращать не то что GET и вообще может не поддерживаться. Потому я бы HEAD не рекомендовал.

Тебе нужен HTTP метод HEAD

Да это не важно вообще. Я же говорю, основные тормоза в ожидании ответа, а текст и так быстро передается, там существенной разницы не будет

Я же говорю, основные тормоза в ожидании ответа

Запускай запросы в отдельных нитях. Или делай как в nginx/lighttpd, обработкой сокетов пачками.

Дело во взаимном несоответствии вопросов. Вроде локальный софт, для которого порты и не нужны, а вроде и http. Хотя хз нужно ли для петли порты дергать - я профан тут

Запускай запросы в отдельных нитях

Есть же ограничение на количество нитей. Я хотел сделать полностью асинхронную реализацию чтобы ни один запрос не дожидался ответа. А обработка пачками не решит ничего, потому что все равно ограничение на кол-во пр-ссов. вся соль в том чтобы выкинуть ожидание, рукопожатие.

Спасибо большое, значит это невозможно.

Нда, и все же меня терзают сомнения, ведь аджакс как-то отсылает асинхронные запросы.

В данном контексте слово «асинхронный» вообще не о том. Это только для браузера этот запрос «асинхронный» (имеется в виду «не влекущий одновременное перерисовывание содержимого вкладки»), а в остальном - совершенно обычный обмен в рамках ранее установленного TCP-соединения (см. http://en.wikipedia.org/wiki/HTTP_persistent_connection и до кучи http://en.wikipedia.org/wiki/HTTP_pipelining, оно хоть и не про твою задачу, но знаний добавит).

Вся эта красота не отменяет необходимости осуществления TCP Handshake.
Пакет с огрызком HTTP вне установленного ранее TCP соединения будет проигнорирован стеком машины, на которой работает сервер, и до самого сервера (демона) вообще не дойдет.

Нельзя гонять протокол, работающий поверх TCP, игнорируя правила работы TCP. Все просто.

Спасибо. Значит надежды нет. А я блин, уже запостил тему про аджакс в вебдевелопмент. Поспешил мальца. А это что же получается, браузер средствами ОС устанавливает соединение при каждом аджакс запросе, значит обращение к ОС осуществляются в порядке очереди? Или нитями? Если нитями, получается, что возможна ошибка макс кол-ва одновременных соединений?

получается, что возможна ошибка макс кол-ва одновременных соединений?

Я ж написал: «в рамках ранее установленного TCP-соединения». Лимиты могут вылезти, когда ты захочешь гонять запросы к куче серверов разом.
Ну то есть как у тебя оно и обстоит.

А обработка пачками не решит ничего, потому что все равно ограничение на кол-во пр-ссов.

Настроенный nginx держит десятки (а то и сотни) тысяч запросов в секунду. Естественно они пересекаются по времени, и одновременно могут быть активны тысячи соединений. И всё одним процессом с одной нитью. Так что решит. Просто сделать аналог может оказаться нетривиальной задачей.

Понял спасибо, больше не буду бестолковиться. Извините еще раз.

Нельзя гонять протокол, работающий поверх TCP, игнорируя правила работы TCP

HTTPU?

Если не нужна проверка целостности, вроде UDP есть. Anon про мультикаст говорил, сто процентов знает

работающий поверх TCP
работающий поверх TCP
работающий поверх TCP

Если не нужна проверка целостности, вроде UDP есть

Не, мне нужна проверка ответа сервера: 200 или нет.

Чтобы получить данные по tcp, по http, работающему поверх tcp, нужно установит содинение. Не обязательно для каждого соединения запускать свой curl, можно из одной программы установить кучу соединений, причём устанавливать их в не блокирующемся режиме, что соединения устанавливаются параллельно во времени, но это нужно самому писать код, достаточно много.

Ещё можно, приняв тяжёлые вещества, написать стек tcp в user-space, но это ещё больше кода.

Судя по вашим вопросам, вам нужно долго учить матчасть, прежде чем писать подобных код. Программирование на Си, man 2 connect, man 2 select.

Судя по вашим вопросам, вам нужно долго учить матчасть, прежде чем писать подобных код

Да, все так, и при этом я все равно не достигну главной цели - асинхронности запросов-ответов.

Вы настолько не уверены в себе, что не верите, что сможете написать работающую программу на Си?

Да, я си не знаю, и я так понял, что асинхронная реализация в принципе невозможна. Или я ошибаюсь? Если возможна, то как это должно выглядеть? Возможно я найду обходные пути, если пойму принцип возможной реализации.

Я не знаю, асинхронная это или нет, но возможно такая реализация. Приложение делает, допустим, 1000 сокетов в неблокирующемся режиме, всем им «одновременно» командует установить соединение, потом через select() отслеживает за именением состояни этих сокетов, пишет запросы и читает ответы. Пока один сокет находится в состоянии установления соединения, в другой может писаться запрос.

А так, я ещё добавлю, что отправляя запрос нужно всегда расчитывать на получении ответа, и запрос и ответ это пакеты/байты, поэтому нельзя просто так фигачить запросы с бесконечной скоростью, нужно думать, чтобы ответы успевали пролазить в канал ограниченной ширины. А, если это ещё запросы к одному серверу, то вобще можно бан по ip получить.

Спасибо большое, я подумаю над этим. Сейчас уже голова не соображает чтобы осмыслить.

Есть же ограничение на количество нитей.

Я непонимаю откуда ты берешь все эти ограничения? Программа работает под линуксом или виндой? Если под линуксом то попробуй запускать из под рута.

Какая нахрен асинхронная реализация - выкинь это говно, ибо это всё «ассинхронщина» уровня питушарского недовеба - тебе уже об этом выше сказали.

Что возможно? Попинать каждый порт? Да. Заслать гет и получить ответ? Тоже. Это строчек 50-100 лапши на сишке - иди осиливай.

То, что тебе пацаны рассказываю, типа вебсервер много кода и прочее - не слушай, ибо они анскильные. В их тормазных говнонгинксах 0.1% строк «вебсервера» - остальное - это http кастыли и прочее говно.

Тебе же на это класть - поклади.

Начнем с простого - что ты понимаешь под открытием порта?

PS. Если забыть про хттп, то просканировать порты на удаленных машинах можно через RAW сокеты. Эта штука позволяет писать данные напрямую в эзернет. Т.е шлешь сразу много пакетов tcp с syn флагом и ждешь реакции.

началась передача чего-либо поверх tcp/udp надо для начала установить соединение.

udp

установить соединение

Что для udp значит установить соединение?

равно как и для tcp, создать сокеты.

Тройное рукопожатие Вам о чем-нибудь говорит?

говорит