мы ж вроде не за виртуалки говорили, не?

ну сервер уровня "виртуалка" или что там продали за 25 евро

Вы же вчера это спрашивали в другоей группе и вам пример кода постнул для обхода мапы.

Дык я понял, но так мапу не обойти, ибо сложная она шо пипец. Проще пойти другим путём.

Дык я понял, но так мапу не обойти, ибо сложная она шо пипец. Проще пойти другим путём.

там был switch type. Почему им нельзя обойти мапу?

там был switch type. Почему им нельзя обойти мапу?

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

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

ну ты сам не добирайся - позволь это коду сделать

))

Друзья, подскажите пожалуйста. Используя библиотеку net/http, возможно ли отправить GET запрос и грубо говоря забросить его? В стиле UDP не ждать ответа и не принимать response body.

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

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

А вот как его не принять?

Если это возможно конечно..

не читать body

Но память для боди все равно аллоцируется?

сами данные, конечно, успеют приехать

если их не слишком много, и они влезли в буфер

буфер? да, это мы не контролируем в go

Хм. Может тогда руками открывать сокет?

Хотя это нужно самому делать TCP handshake и тд

цель-то какая?

обязательно GET, HEAD не подойдет?

а скажите пожалуйста это я дебил или что то не так в консерватории... вот смотрю описание вакансии и skills, как то у меня все это Python, PHP, MySQL, Docker, Kubernetes, Go не сходитсяс 90-115k. Судя по описанию там все прям expert, правда python/php на выбор :)

цель-то какая?

Отправить серверу HTTP GET и не ждать ответа + даже не аллоцировать под ответ память

Хотя это нужно самому делать TCP handshake и тд

нет никакого http handshake

открываешь, отправляешь хедера, закрываешь

на той стороне - ошибка, "client closed connection premature"

а скажите пожалуйста это я дебил или что то не так в консерватории... вот смотрю описание вакансии и skills, как то у меня все это Python, PHP, MySQL, Docker, Kubernetes, Go не сходитсяс 90-115k. Судя по описанию там все прям expert, правда python/php на выбор :)

обсуждать нечего. вилки на рынке отличаются в разы в зависимости от.

обсуждать нечего. вилки на рынке отличаются в разы в зависимости от.

да кстати по локации это Кали, еще там в списке монга, редис, Aerospike

нет никакого http handshake

А вот это? Возможно что-то путаю.

это tcp handshake

Хотя это нужно самому делать TCP handshake и тд

может вы про ssl/tls ?

это tcp handshake

Ну так если HTTP поверх tcp, то придётся это самому реализовывать..

это уже реализация tcp

если сами http пишете поверх готового tcp, то tcp-хэндшейк зачем самому писать?

если сами http пишете поверх готового tcp, то tcp-хэндшейк зачем самому писать?

Не пишу. Мне нужно отправить GET запрос и не ждать от него ответа / отвергнуть ответ.

Не пишу. Мне нужно отправить GET запрос и не ждать от него ответа / отвергнуть ответ.

Закройте просто соединение.

Закройте просто соединение.

Логично

Логично

Есть риск, что веб-сервер просто прибъёт обработчика этого запроса, если клиент (т.е. ваша программа) закроет соединение. Апач так точно делает.

Логично

Можно еще попробовать ResponseHeaderTimer https://golang.org/pkg/net/http/#Transport в 0 поставить.

Не пишу. Мне нужно отправить GET запрос и не ждать от него ответа / отвергнуть ответ.

если вы отправляете запрос по протоколу то будьте добры его соблюдать.

Есть риск, что веб-сервер просто прибъёт обработчика этого запроса, если клиент (т.е. ваша программа) закроет соединение. Апач так точно делает.

Вот интересно, а если его закрыть, но не отправлять close серверу.

Тогда апач не узнает, что сокет закрыт (?)

Узнает конечно, на стороне сервера это будет выглядеть как клиент бросил коннект

Узнает конечно, на стороне сервера это будет выглядеть как клиент бросил коннект

Узнает как только он закончит обслуживать запрос, так? То есть обработчик не убьётся.

Узнает как только он закончит обслуживать запрос, так? То есть обработчик не убьётся.

Я б не стал на это расчитывать. Насколько я понимаю, это всё нужно для какого-то вебхука. Лучше просто ограничить время ответа несколькими секундами. А сам ответ считывать и выбрасывать.

Я б не стал на это расчитывать. Насколько я понимаю, это всё нужно для какого-то вебхука. Лучше просто ограничить время ответа несколькими секундами. А сам ответ считывать и выбрасывать.

Но если ответ в несколько MB, то хотелось бы их просто не принять. Иначе сборщик будет постоянно работать.

Ограничить и размер ответа тоже. Как только получил первые пару кб - можно и закрыть соединение.

Ограничить и размер ответа тоже. Как только получил первые пару кб - можно и закрыть соединение.

Хороший подход

Спасибо за подсказки.

Вот интересно, а если его закрыть, но не отправлять close серверу.

пошлите в хедере лучше "Connection: Close" :)

Это же просто означает не использовать keepalive. Ответ от сервера то все равно будет отправлен

Узнает как только он закончит обслуживать запрос, так? То есть обработчик не убьётся.

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

Это же просто означает не использовать keepalive. Ответ от сервера то все равно будет отправлен

Мне не столь важно ответ от сервера. Главное чтобы он обработал запрос.

Это же просто означает не использовать keepalive. Ответ от сервера то все равно будет отправлен

ну сервер так вроде отвечает когда не хочет поддерживать конект и закрывается после ответа, а вот от клиента если послать, то хз че будет я так не делал никогда) p.s. но вообще да фигня HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. т.е. респонсе пойдет

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

То, что нужно 👍

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

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

Можно еще размер TCP окна почти в ноль выставить ... :))

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

так может не гетом посылать а каким нибудь OPTIONS там есть Successful response has body котороу можно в false выставить p.s. хотя наверно нифига, я что то попутал, не помню че оно делать должно

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

а зачем вам свой лоадтестер, когда есть пачка готовых?

а зачем вам свой лоадтестер, когда есть пачка готовых?

Ну вот решили делать свой.

Ну вот решили делать свой.

так а зачем?

Не пишу. Мне нужно отправить GET запрос и не ждать от него ответа / отвергнуть ответ.

Вам нужно shutdown но не close, тогда сервер не получит RST и будет доволен. http://man7.org/linux/man-pages/man2/shutdown.2.html

так может не гетом посылать а каким нибудь OPTIONS там есть Successful response has body котороу можно в false выставить p.s. хотя наверно нифига, я что то попутал, не помню че оно делать должно

Но обработчик ждёт GET с параметрами..

Вам нужно shutdown но не close, тогда сервер не получит RST и будет доволен. http://man7.org/linux/man-pages/man2/shutdown.2.html

Спасибо большое, посмотрю.

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

Оборачиваете switch в функцию и рекурсируйте сколько хотите. 🤦‍♂ Любопытно уже, что вас привело в программирование и как давно вы там. 😏

Но обработчик ждёт GET с параметрами..

тогда нужно руками открывать сокет и формировать запрос, а когда сервер пришлет ACK после отсылки FIN сразу закрывать. Точно не помню, там вроде клиент FIN,ACK одновременно шлет и это а линуксе используется, значит что клиент не собирается ждать ответа. Это вроде не нарушает ничего p.s. не опять путаю, обычный FIN, ASK ждет ответа, а half-duplex termination RST не ждет. но в любом случае это нужно руками все делать

А вдруг сервер отвечает 3xx Redirect ? По хорошему load tester должен следовать ему.

Ну и всякие там cookie иногда надо сохранять для сессии. Зависит от требоований, конечно.

вообще проще всего обычным curl отправить запрос и просто выставить connection_timeout какой то очень маленький

Вчера смотрел чат - писали вирус. Сейчас, похожу, дудос систему 😄

500-800 строчек кода в го файле это норма?

зависит

я бы нарезал на несколько - обычно такой объем это уже несколько сущностей

Оборачиваете switch в функцию и рекурсируйте сколько хотите. 🤦‍♂ Любопытно уже, что вас привело в программирование и как давно вы там. 😏

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

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

почему рекурсия -кривой способ ? :)

жрет стек

жрет стек

ну для начала надо упереться в стенку, иначе это какойто оверинжениринг

есть несколько паттернов, использование которых надо оправдывать

Ну блин, для если у тебя разбор вложенной структуры сжирает при рекурсии весь стек, то у тебя уже другие проблемы начинаются а-ля давайте делать стриминговый json парсер

есть несколько паттернов, использование которых надо оправдывать

а "весело" -это нормальное оправдание ? :)

полный перебор, рекурсия, битовая упаковка...