Здравствуйте, Iso12, Вы писали:

G>>http не проще будет?
I>Думаю нет, сервисы должны работать с клиентами и обмениваться между собой данными.

http хорош тем, что он обычно работает даже у клиентов, у которых злобные админы зарезали весь трафик, кроме вебовского.

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

Готовые примеры — websocket и http/2

Кстати, в Go это все есть, как часть стандартной библиотеки

Здравствуйте, Iso12, Вы писали:

I>Добрый день,

I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.II
I>...

I>Кто что может посоветовать?

Провел бы сразу опрос, кто считает какой язык программирования и протокол лучшим.
Я голосую за D.

Здравствуйте, Ikemefula, Вы писали:


I>Что-то навроде мониторинга ? Почему HTTP не подходит и как считаешь оверхед ?

Да, что-то вроде этого. HTTP не подходит, потому что сервис должен уметь находить другие сервисы в сети и к ним подсоеденятся ипередовать информацию о своих клиентах другим сервисам и получить такие же данные от других сервисах. Имеем не Server-Client архитектуру а Mesh network.

Здравствуйте, lpd, Вы писали:



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

Здравствуйте, Iso12, Вы писали:

scf>>Какие языки и API знаете?
I>Писал на C++. Но я думаю выучить и опробовать новый язык будет не проблема.

Выучить можно всё что угодно, но если понадобится другой(ие) программист(ы), то возникает вопрос, какого спеца найти проще: GO, Rust или С++. Что-то я думаю ответ здесь однозначен.

Здравствуйте, Iso12, Вы писали:

I>Да, что-то вроде этого. HTTP не подходит, потому что сервис должен уметь находить другие сервисы в сети и к ним подсоеденятся ипередовать информацию о своих клиентах другим сервисам и получить такие же данные от других сервисах. Имеем не Server-Client архитектуру а Mesh network.

Ты говоришь про топологию, а я говорю про протокол. HTTP вообще говоря cпокойно может применяться даже таких вот сетях.

Здравствуйте, Ikemefula, Вы писали:


I> Ты говоришь про топологию, а я говорю про протокол. HTTP вообще говоря cпокойно может применяться даже таких вот сетях.

Что не правильно? Протокол и разрабатывался под определённую топологию.
Цитирую с Вики:

Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

Потребителей (клиентов), которые инициируют соединение и посылают запрос;
Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).

Мне нужно не то что модно, а то что удобно и практично.
По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.

Здравствуйте, Iso12, Вы писали:

I>Здравствуйте, Ikemefula, Вы писали:

I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).

почему нельзя сделать push?

Здравствуйте, Iso12, Вы писали:

I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).

Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http

Сразу узнавали — такого не бывает. Всегда есть задержка.

I>Мне нужно не то что модно, а то что удобно и практично.
I>По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.

А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?

Здравствуйте, Sharov, Вы писали:


S>почему нельзя сделать push?

Как я понимаю,под Push-ем Вы имеете ввиду вот это.
Я наверное человек консервативного мышления, и наверное не понимаю всей прелести HTTP.
Но для меня проще взять TCP-Socket и организовать на нём обмен асинхронными и сихронными пакетами,
чем организовывать тоже самое на WebSockete и HTML5.

Здравствуйте, Ikemefula, Вы писали:

I>Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http

Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.


I>>Мне нужно не то что модно, а то что удобно и практично.
I>>По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.

I>А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?

Так зачем обёртывать в HTTP если можно передать напрямую?

Здравствуйте, Iso12, Вы писали:

I>>Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http

I>Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.

Ну вот часть HTTP уже изобретена

Посмотри http://zeromq.org/ Там уже много чего готового для тебя.

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

I>>А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?

I>Так зачем обёртывать в HTTP если можно передать напрямую?

Вот это "обертывание" почти ничего не стоит, если только ты не биржу пишешь и тебе надо выжимать мили- и даже микросекнды задержки.

Зато готовая инфраструктура искаропки — всё что надо, работает. Можно сразу начинать прикладной код писать.

Здравствуйте, Iso12, Вы писали:

I>Как я понимаю,под Push-ем Вы имеете ввиду вот это.
I>Я наверное человек консервативного мышления, и наверное не понимаю всей прелести HTTP.
I>Но для меня проще взять TCP-Socket и организовать на нём обмен асинхронными и сихронными пакетами,
I>чем организовывать тоже самое на WebSockete и HTML5.

В результате Вы придумаете свое колесо, вместо того, чтобы воспользоваться уже сущ. наработками. Для http куча всего есть и он много для чего подходит.
Я пока что не увидел из планируемой функ-ти того, что нельзя сделать на http. Ну mesh-топология и что? Ну обменивайтесь инф-ей через http.

Здравствуйте, Iso12, Вы писали:

I>Я наверное человек консервативного мышления, и наверное не понимаю всей прелести HTTP.

В HTTP всё уже изобретено, и куча проблем, узких место проработана, задокументирована. Осталось только пользоваться.

I>Но для меня проще взять TCP-Socket и организовать на нём обмен асинхронными и сихронными пакетами,
I>чем организовывать тоже самое на WebSockete и HTML5.

Не совсем понятно, чем это проще. Возможно привычнее ? Для хттп берется нужная либа и всё zeromq — нужная либа и всё. Если начинать с tcp-socket, то такую либу надо написать, отладить, продумать все кейсы, переписать, и так каждый раз при обнаоружении проблем или изменении требований/топологии и тд.

Скажем, как только клиенты окажутся разных сетях, фокусы с UDP резко усложнятся и тут снова или писать-писать-писать, или брать готовую либу.

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

Как то так.

Здравствуйте, Sharov, Вы писали:

S>Я пока что не увидел из планируемой функ-ти того, что нельзя сделать на http. Ну mesh-топология и что? Ну обменивайтесь инф-ей через http.

Товарищ похоже задумал писать "на сокетах" и загадал загадку. Чем больше его отговариваешь и предлагаешь взять внятный инструмент, тем сильнее у него ощущение что писать надо "на сокетах".

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Iso12, Вы писали:

I>>Я наверное человек консервативного мышления, и наверное не понимаю всей прелести HTTP.

I>В HTTP всё уже изобретено, и куча проблем, узких место проработана, задокументирована. Осталось только пользоваться.

Да что уж там: пускай браузер сразу встраивает и пишет все на AngularJS.

I>Скажем, как только клиенты окажутся разных сетях, фокусы с UDP резко усложнятся и тут снова или писать-писать-писать, или брать готовую либу.

Чем усложняется? broadcast? — его не сделать на HTTP, если он вдруг нужен.

Здравствуйте, Ikemefula, Вы писали:

I>>Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.
I>Ну вот часть HTTP уже изобретена
I>Посмотри http://zeromq.org/ Там уже много чего готового для тебя.

Вот из твоего текста что-то непонятно, ты в итоге то советуешь человеку использовать HTTP или ZeroMQ? )

Здравствуйте, lpd, Вы писали:

I>>В HTTP всё уже изобретено, и куча проблем, узких место проработана, задокументирована. Осталось только пользоваться.

lpd>Да что уж там: пускай браузер сразу встраивает и пишет все на AngularJS.

Браузер использует очень малую часть HTTP.

I>>Скажем, как только клиенты окажутся разных сетях, фокусы с UDP резко усложнятся и тут снова или писать-писать-писать, или брать готовую либу.

lpd>Чем усложняется? broadcast? — его не сделать на HTTP, если он вдруг нужен.

Скажем, клиенты окажутся со временем в разных сетях. Что ты будешь делать ? А как ты будешь перегрузку контролировать ? Шифрование понадобится ? Аутентификация ?

Здравствуйте, alex_public, Вы писали:

I>>>Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.
I>>Ну вот часть HTTP уже изобретена
I>>Посмотри http://zeromq.org/ Там уже много чего готового для тебя.

_>Вот из твоего текста что-то непонятно, ты в итоге то советуешь человеку использовать HTTP или ZeroMQ? )

Я в курсе, что ты плохо читаешь. zeromq — это что бы легче было HTTP изобретать.

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, lpd, Вы писали:

I>Скажем, клиенты окажутся со временем в разных сетях. Что ты будешь делать ? А как ты будешь перегрузку контролировать ? Шифрование понадобится ? Аутентификация ?

В разных сетях UDP вполне работает, кроме сложностей с broadcast.

Данных будет не много, время передачи данных не критично.

Т.е. контроль перегрузки не нужен.
Шифрование можно сделать на OpenSSL.
Из задачи, описанной ТС, неясно, что именно ему даст использование http, кроме некоторого возможного оверхеда парсинга заголовков. Поэтому не вижу причин натягивать высокоуровневый протокол без необходимости. Хотя, может, это и не смертельно.