А посоветуйте плз. Есть у меня штука, вынесенная в отдельный сервис: она будет ходить по различному оборудованию и собирать с него кучу самых разнообразных данных. В результате - структурированные однообразные ответы, либо ошибка. В неё пулять задание (объекты для обхода) будет какая-то другая штука. Так вот, думаю я о том, как и что лучше сделать: делать http(s)-запрос с нужными параметрами, и ждать ответ, либо поднимать tcp-сессию и гонять туда-обратно нужные данные. Учитывая, что опрос одной железки может и на 5-10 минут затянуться, а таких задания может быть несколько тысяч в течение 5 минут - оверхед (в смысле сложности) с сокетами и своим мини-протоколом может быть оправдан...

@twentydraft ?

заблочили в старой группе, думаю за какие грехи

Пыхой балуешься по ночам, наверное

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

Не произноси это слово на п в приличном обществе!

А посоветуйте плз. Есть у меня штука, вынесенная в отдельный сервис: она будет ходить по различному оборудованию и собирать с него кучу самых разнообразных данных. В результате - структурированные однообразные ответы, либо ошибка. В неё пулять задание (объекты для обхода) будет какая-то другая штука. Так вот, думаю я о том, как и что лучше сделать: делать http(s)-запрос с нужными параметрами, и ждать ответ, либо поднимать tcp-сессию и гонять туда-обратно нужные данные. Учитывая, что опрос одной железки может и на 5-10 минут затянуться, а таких задания может быть несколько тысяч в течение 5 минут - оверхед (в смысле сложности) с сокетами и своим мини-протоколом может быть оправдан...

А посоветуйте плз. Есть у меня штука, вынесенная в отдельный сервис: она будет ходить по различному оборудованию и собирать с него кучу самых разнообразных данных. В результате - структурированные однообразные ответы, либо ошибка. В неё пулять задание (объекты для обхода) будет какая-то другая штука. Так вот, думаю я о том, как и что лучше сделать: делать http(s)-запрос с нужными параметрами, и ждать ответ, либо поднимать tcp-сессию и гонять туда-обратно нужные данные. Учитывая, что опрос одной железки может и на 5-10 минут затянуться, а таких задания может быть несколько тысяч в течение 5 минут - оверхед (в смысле сложности) с сокетами и своим мини-протоколом может быть оправдан...

А посоветуйте плз. Есть у меня штука, вынесенная в отдельный сервис: она будет ходить по различному оборудованию и собирать с него кучу самых разнообразных данных. В результате - структурированные однообразные ответы, либо ошибка. В неё пулять задание (объекты для обхода) будет какая-то другая штука. Так вот, думаю я о том, как и что лучше сделать: делать http(s)-запрос с нужными параметрами, и ждать ответ, либо поднимать tcp-сессию и гонять туда-обратно нужные данные. Учитывая, что опрос одной железки может и на 5-10 минут затянуться, а таких задания может быть несколько тысяч в течение 5 минут - оверхед (в смысле сложности) с сокетами и своим мини-протоколом может быть оправдан...

а чем вариант с парой очередей не нравится?

HTTP/1.1 ни в коем случае, он не умеет multiplex. HTTP/2 можно, он не будет блокировать другие запросы TPC/IP можно, но сложно а ещё можно https://github.com/qbeon/webwire-go, это WebSocket со всеми удобствами

Сделайте асинхронную очередь. На сервисе который выдаёт задачи - отправить задачу и периодически пинговать статус. На сервисе который выполняет - принять и поставить в очередь на обход, сохранить статус у себя

В смысле? Я скорее нн про очереди, а про интерфейс общения между сервисами

2 запроса: один принимает пачку заданий и возвращает id каждого задания, второй - принимает пачку id и возвращает статусы

громоздко

так себе, если можно послать запрос: ctx := context.WithTimeout(context.Background(), 50 * time.Second) result, err := client.Request(ctx, "getSomething", /*data*/) и проверить, удался ли запрос, провалился по причине ошибки или timeout'нулся: if err != nil { if wwr.IsTimeoutErr(err) { // timeout! } else { // error! // err.Code // err.Message } } думаю это намного элегантнее чем polling особенно в связке с goroutine'ами где можно просто запустить 1к горутин за заблокировать их на этих запросах

а если воркер грохнется?

А если сеть упадёт?

а зачем в этой задаче мультиплексирование?

а если воркер грохнется?

хмм, момент, ещё раз перечитал внимательно. Тут говорится о нескольких тысячах параллельных запросов. Если речь идёт о 1к конкурентных клиентов то да мультиплекс особо не нужен.... НО! есть огромное НО: но если вдруг таки понадобится одновременно с 1 клиента посылать например 2 запроса а у нас HTTP/1.1 то нам кранты, ибо если первый запрос заблокирует связь на 5-10 минут, то нам придётся создавать для каждого запроса отдельное подключение, а это 2х нагрузка на сервер если-же изначально у нас имеется мултикплекс, то такая проблема исключена в принципе, запросы не блокируют друг друга

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

хмм, момент, ещё раз перечитал внимательно. Тут говорится о нескольких тысячах параллельных запросов. Если речь идёт о 1к конкурентных клиентов то да мультиплекс особо не нужен.... НО! есть огромное НО: но если вдруг таки понадобится одновременно с 1 клиента посылать например 2 запроса а у нас HTTP/1.1 то нам кранты, ибо если первый запрос заблокирует связь на 5-10 минут, то нам придётся создавать для каждого запроса отдельное подключение, а это 2х нагрузка на сервер если-же изначально у нас имеется мултикплекс, то такая проблема исключена в принципе, запросы не блокируют друг друга

Зачем? Что мешает принимать и отдавать пачкой?

хмм, момент, ещё раз перечитал внимательно. Тут говорится о нескольких тысячах параллельных запросов. Если речь идёт о 1к конкурентных клиентов то да мультиплекс особо не нужен.... НО! есть огромное НО: но если вдруг таки понадобится одновременно с 1 клиента посылать например 2 запроса а у нас HTTP/1.1 то нам кранты, ибо если первый запрос заблокирует связь на 5-10 минут, то нам придётся создавать для каждого запроса отдельное подключение, а это 2х нагрузка на сервер если-же изначально у нас имеется мултикплекс, то такая проблема исключена в принципе, запросы не блокируют друг друга

HTTP/1.1 ни в коем случае, он не умеет multiplex. HTTP/2 можно, он не будет блокировать другие запросы TPC/IP можно, но сложно а ещё можно https://github.com/qbeon/webwire-go, это WebSocket со всеми удобствами

Процесс, упадет по сегфолту или панике

пачками больше кода и сложнее получится, ты считай переизобретаешь в таком случае мультиплекс, который в webwire имеется по умолчанию. Да и работать оно будет гораздо хуже.. например у тебя 2 типа запроса: первый занимает 5-10 минут, второй секунд 30, так вот без мультиплекса придётся в 2 соединения шмалять, ибо первый блокирует подключение к чертям на 10 минут и второй не сможет одновременно в 30 секундных интервалах гоняться или я что-то не так понял?

Именно с нескольких клиентов куча запросов, да. С 1..5

каждый клиент по 1 запросу или несколько?

Тут уже обсудили что HTTP 1 тема?

Кажжый - тысячи

каждый клиент по 1 запросу или несколько?

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

Зачем тут мультиплекс?

ну он же говорит: 1 клиент = 1000 запросов

Но дико не нравится

хм?

1000 "выдаваемых заданий"

ааа, ну это конечно другое дело. тогда да, мультиплекс будет не нужен, но, повторюсь, если он вдруг понадобится по каким либо причинам в будущем (клеитн теперь не только проверяет статус 100500 железок, но и статус XYZ) тогда придётся всё переписывать, ибо невыгодно выйдет без мултиплекса я о том что мультиплекс хорошо иметь за-пазухой на всякий пожарный

Да не нужен он тут от слова совсем

H2 по сути только глупым браузерам нужен, где вшит лимит 2 подключения на домен ?

Нет, оно надо только там где люди не умеют батчить и на long fat net

Но дико не нравится

Без мультиплекса — збс.

ну раз так, тогда и HTTP/2 не нужен и вообще дураки его изобрели по непонятной причине)) мультиплекс это очень важная фича, и я не уверен говорим ли мы действительно об одном и том-же

ну раз так, тогда и HTTP/2 не нужен и вообще дураки его изобрели по непонятной причине)) мультиплекс это очень важная фича, и я не уверен говорим ли мы действительно об одном и том-же

Чем?

при чем тут константа?

1) громоздкостью) 2) сдох "выдающий задания", а "исполнитель" результаты так и держит в памяти. Надо крутить таймауты. Геморройно и громоздко

1) громоздкостью) 2) сдох "выдающий задания", а "исполнитель" результаты так и держит в памяти. Надо крутить таймауты. Геморройно и громоздко

поэтому я и предложил запускать 1000 конкурентных запросов с индивидуальными таймаутами и ошибками, нежели 1 запрос с 1000 заданиями

Гугл изобрёл Quic чтобы ускорить свой сайтик.

ну так надо дополнить "отдать список всех заданий"

А если несколько независимых "контролеров"? Нах им чужие задания?

nyet

>мультиплекс это очень важная фича нет, потому что HOL Blocking.

пфф, ну добавить id каждому

HOL как-раз и решается мултиплексом, поэтому я немного удивлён слышать что мултиплекс не нужен?!

у тебя там внизу tcp-соединение, поверх которого фрейминг. если какая беда случается, то аффектит вообще все, а не только 1 коннект

ну ясное дело, однако какова вероятность?

шумный wifi, перегруженная 3g/4g сота