Здравствуйте, Iso12, Вы писали:
Pzz>>Я бы выбрал Go I>Почему?
Ну, поскольку данных не очень много, то производительность значения не имеет (Go не то, чтобы совсем уж тормоз, но раза в два Си, а значит, C++ и Русту, проигрывает).
С другой стороны, ты просил кроссплатформенность. С ней у Go очень хорошо. Программу типа сетевого сервиса можно собрать из одних и тех же исходников, и если не надо чего-то очень уж экзотического, то никакого ветвления (ни на этапе компиляции, не во время исполнения) в зависимости от операционной системы вообще не потребуется. Кроме того, стандартная библиотека Go очень практична, и для програм такого плана в ней есть все, что нужно.
Кроме того, у Go очень хорошо налажена кросс-компиляция. Не является проблемой сидя на одной из перечисленных платформ собирать программу под все остальные. Что довольно удобно, попробуй-ка сделать автоматизированный билд на N платформ, если для его реализации потребуется скоординированная работа N компьютеров, каждый под своей операционной системой.
И наконец, если писать на чистом Go (без использования сторонних сишных библиотек), на выходе получается статически собранный исполняемый файл, у которого вообще нет внешних зависимостей. Распостранять такие програмки — одно удовольствие.
Здравствуйте, Iso12, Вы писали:
I>Добрый день,
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много. I>В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS). I>Смотрю в сторону GO, Rust и С++.
I>Кто что может посоветовать?
Java сработает один раз для всех. Пересобирать не придётся.
Здравствуйте, Iso12, Вы писали:
I>Добрый день,
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много. I>В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS). I>Смотрю в сторону GO, Rust и С++.
I>Кто что может посоветовать?
Здравствуйте, Iso12, Вы писали:
I>>Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http
I>Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.
С UDP тебя ждет куча нюансов, скажем, если узлы будут находиться в разных сетях.
I>>А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?
I>Так зачем обёртывать в HTTP если можно передать напрямую?
Вот это "обертывание" почти ничего не стоит, если только ты не биржу пишешь и тебе надо выжимать мили- и даже микросекнды задержки.
Зато готовая инфраструктура искаропки — всё что надо, работает. Можно сразу начинать прикладной код писать.
Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.
В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS).
Смотрю в сторону GO, Rust и С++.
Здравствуйте, Iso12, Вы писали:
I>Добрый день,
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много. I>В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS). I>Смотрю в сторону GO, Rust и С++.
I>Кто что может посоветовать?
Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.
G>Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.
Программа должна иметь свою не простую логику со множеством соединений и запускаться как сервис.
Поэтому я думаю netcat в моём случае не подойдёт.
Здравствуйте, Iso12, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.
I>Программа должна иметь свою не простую логику со множеством соединений и запускаться как сервис.
В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать?
Если реагировать не надо, то netcat подойдет.
G>В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать? G>Если реагировать не надо, то netcat подойдет.
Да, должна принимать, реагировать и отправлять дальше другим клиентам.
Здравствуйте, Iso12, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать? G>>Если реагировать не надо, то netcat подойдет. I>Да, должна принимать, реагировать и отправлять дальше другим клиентам.
Здравствуйте, Iso12, Вы писали:
I>Здравствуйте, gandjustas, Вы писали:
G>>http не проще будет? I>Думаю нет, сервисы должны работать с клиентами и обмениваться между собой данными.
Под эти задачи http прекрасно подходит.
Здравствуйте, Iso12, Вы писали:
G>>http не проще будет? I>Думаю нет, сервисы должны работать с клиентами и обмениваться между собой данными.
А какие еще требования и ограничения есть ? Нагрузка, скорость передачи, количество клиентов, задержки всякие и тд и тд. И что значит "обмениваться между собой" Если начать с UDP большой шанс, что изобретешь TCP. А начав с TCP можно легко изорбрести HTTP
I>А какие еще требования и ограничения есть ? Нагрузка, скорость передачи, количество клиентов, задержки всякие и тд и тд. И что значит "обмениваться между собой" Если начать с UDP большой шанс, что изобретешь TCP. А начав с TCP можно легко изорбрести HTTP
К сервисам подключаются локально клиентские программы. Сервисы обмениваются между сабой информацией о подключенных клиентских программах и их состояниях. Клиентслие программы могут иметь различные состояния.
Нужно построить динамическую сервисную сеть, это означает сервисная сеть должна реагировать на отключение одного из сервисов и подключение нового сервиса, также и на отключение и подключение клиентов. Оснавная сложность в проекте это маштабируемость и реорганизация сервисной сети. Данных будет не много, время передачи данных не критично.
Я думаю что HTTP к это задачи не подходит и будет overhead-ом.
Здравствуйте, Iso12, Вы писали:
I>>А какие еще требования и ограничения есть ? Нагрузка, скорость передачи, количество клиентов, задержки всякие и тд и тд. И что значит "обмениваться между собой" Если начать с UDP большой шанс, что изобретешь TCP. А начав с TCP можно легко изорбрести HTTP
I>К сервисам подключаются локально клиентские программы. Сервисы обмениваются между сабой информацией о подключенных клиентских программах и их состояниях. Клиентслие программы могут иметь различные состояния. I>Нужно построить динамическую сервисную сеть, это означает сервисная сеть должна реагировать на отключение одного из сервисов и подключение нового сервиса, также и на отключение и подключение клиентов. Оснавная сложность в проекте это маштабируемость и реорганизация сервисной сети. Данных будет не много, время передачи данных не критично. I>Я думаю что HTTP к это задачи не подходит и будет overhead-ом.
Что-то навроде мониторинга ? Почему HTTP не подходит и как считаешь оверхед ?
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.
Лучше возьмите готовый. В зависимости от конкретики (типы, объемы данных и требования к задержкам) это может быть как просто "труба через SSH" (SSH tunnel), так и что-то иное.
Здравствуйте, Iso12, Вы писали:
I>Добрый день,
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.II I>...
I>Кто что может посоветовать?
Провел бы сразу опрос, кто считает какой язык программирования и протокол лучшим.
Я голосую за D.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
I>Что-то навроде мониторинга ? Почему HTTP не подходит и как считаешь оверхед ?
Да, что-то вроде этого. HTTP не подходит, потому что сервис должен уметь находить другие сервисы в сети и к ним подсоеденятся ипередовать информацию о своих клиентах другим сервисам и получить такие же данные от других сервисах. Имеем не Server-Client архитектуру а Mesh network.
lpd>Провел бы сразу опрос, кто считает какой язык программирования и протокол лучшим. lpd>Я голосую за D.
Вообще-то думал об этом но судя по количеству ответов здесь, боюсь не взлетит.
Здравствуйте, Iso12, Вы писали:
scf>>Какие языки и API знаете? I>Писал на C++. Но я думаю выучить и опробовать новый язык будет не проблема.
Выучить можно всё что угодно, но если понадобится другой(ие) программист(ы), то возникает вопрос, какого спеца найти проще: GO, Rust или С++. Что-то я думаю ответ здесь однозначен.
Здравствуйте, Iso12, Вы писали:
I>Да, что-то вроде этого. HTTP не подходит, потому что сервис должен уметь находить другие сервисы в сети и к ним подсоеденятся ипередовать информацию о своих клиентах другим сервисам и получить такие же данные от других сервисах. Имеем не Server-Client архитектуру а Mesh network.
Ты говоришь про топологию, а я говорю про протокол. HTTP вообще говоря cпокойно может применяться даже таких вот сетях.
I> Ты говоришь про топологию, а я говорю про протокол. HTTP вообще говоря cпокойно может применяться даже таких вот сетях.
Что не правильно? Протокол и разрабатывался под определённую топологию.
Цитирую с Вики:
Основой HTTP является технология «клиент-сервер», то есть предполагается существование:
Потребителей (клиентов), которые инициируют соединение и посылают запрос;
Поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).
Мне нужно не то что модно, а то что удобно и практично.
По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.
Здравствуйте, Iso12, Вы писали:
I>Здравствуйте, Ikemefula, Вы писали:
I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).
Здравствуйте, Iso12, Вы писали:
I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали. "Запрос-ответ" (HTTP) здесь не совсем подходит, так как в этом случае надо реализовывать Polling (постоянные запросы для клиентов).
Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http
Сразу узнавали — такого не бывает. Всегда есть задержка.
I>Мне нужно не то что модно, а то что удобно и практично. I>По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.
А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?
Как я понимаю,под Push-ем Вы имеете ввиду вот это.
Я наверное человек консервативного мышления, и наверное не понимаю всей прелести HTTP.
Но для меня проще взять TCP-Socket и организовать на нём обмен асинхронными и сихронными пакетами,
чем организовывать тоже самое на WebSockete и HTML5.
Здравствуйте, Ikemefula, Вы писали:
I>Здесь единственная внятная альтернатива, это построение своего протокола на базе UDP. И при этом придется изобрести половину или больше того, что уже есть в http
Так и задумывается : поиск по UDP, потом после ответа, TCP-содинение с обменом синхронныи и асинхронными пакетами.
I>>Мне нужно не то что модно, а то что удобно и практично. I>>По мне, так удобней получать пакеты асинхронно и парсить бинарные пакеты в своём формате, чем html странички.
I>А при чем здесь html странички ? http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?
Так зачем обёртывать в 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, кроме некоторого возможного оверхеда парсинга заголовков. Поэтому не вижу причин натягивать высокоуровневый протокол без необходимости. Хотя, может, это и не смертельно.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, Iso12, Вы писали:
I>Смотрю в сторону GO, Rust и С++.
С практической точки зрения надо выбирать между C++(если скорость очень важна) и JVM. Выгоды от использование двух других языков не будет никакой, а проблем будет вагон и тележка.
N>С практической точки зрения надо выбирать между C++(если скорость очень важна) и JVM. Выгоды от использование двух других языков не будет никакой, а проблем будет вагон и тележка.
Здравствуйте, Iso12, Вы писали:
N>>С практической точки зрения надо выбирать между C++(если скорость очень важна) и JVM. Выгоды от использование двух других языков не будет никакой, а проблем будет вагон и тележка.
I>Какие проблемы?
Скорость и кривизна, особенно если речь идет !=х86
стабильность и качество инструментов
отсутствие кадров
частое "велосипедирование"
Здравствуйте, lpd, Вы писали
lpd>В разных сетях UDP вполне работает, кроме сложностей с broadcast.
Он может работать, а может и не работать. Скажем, для обхода NAT придуманы STUN, TURN, ICE.
lpd>
lpd>Данных будет не много, время передачи данных не критично.
Вот здесь просится чтото готовое и простое. Разве нет?
lpd>Т.е. контроль перегрузки не нужен. lpd>Шифрование можно сделать на OpenSSL.
Да, изобретешь еще кусочек HTTP.
lpd>Из задачи, описанной ТС, неясно, что именно ему даст использование http, кроме некоторого возможного оверхеда парсинга заголовков.
Это даст готовый протокол, с которым можно делать все что угодно. Кроме бродкаста. Но обнаружение сервисов, клиентов можно и без бродкаста делать.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, lpd, Вы писали:
lpd>>Чем усложняется? broadcast? — его не сделать на HTTP, если он вдруг нужен.
M>Все там нормально делается, UPNP и TCP использует, и UDP, и, внезапно и там и там HTTP
Ну, скажем так, это всё ж скорее IGMP
И это, про IPv6 не забываем, господа. Там бродкастов нету (и туда им, спамерам, и дорога).
I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали.
Что то у меня ощущение что ты секретный чатик, убийцу скайпа что ли, пишешь. Чем jabber/xmpp не устраивает? шифрование, бинарные данные, голос, видео, умеет. При подключении клиента "Вася" клиент "Петя" своевременно уведомляется.
Или зачем клиенту знать что к серверу подключился другой клиент? Конкретизируй задачу.
lpd>>>Чем усложняется? broadcast? — его не сделать на HTTP, если он вдруг нужен.
M>>Все там нормально делается, UPNP и TCP использует, и UDP, и, внезапно и там и там HTTP
MD>Ну, скажем так, это всё ж скорее IGMP
IGMP разве не наворот над UDP, дающий ему некоторые доп возможности? Ну, и это транспорт, а на уровне прикладного протокола там вполне HTTP летает и в простых UDP пакетаках, и в бродкастных, и в мультикастных, и адресных, и по TCP/ (сорян, мог с терминологией ошибиться, с OSI не очень )
MD>И это, про IPv6 не забываем, господа. Там бродкастов нету (и туда им, спамерам, и дорога).
Да, но там что-то другое было. И мультикаст вроде есть, хотя не буду утверждать, давно смотрел это дело
Здравствуйте, Ikemefula, Вы писали:
_>>Вот из твоего текста что-то непонятно, ты в итоге то советуешь человеку использовать HTTP или ZeroMQ? ) I>Я в курсе, что ты плохо читаешь. zeromq — это что бы легче было HTTP изобретать.
Для http zeromq как раз не нужен. А вот для обсуждаемой задачки действительно не плохо подходит.
Здравствуйте, alex_public, Вы писали:
_>>>Вот из твоего текста что-то непонятно, ты в итоге то советуешь человеку использовать HTTP или ZeroMQ? ) I>>Я в курсе, что ты плохо читаешь. zeromq — это что бы легче было HTTP изобретать.
_>Для http zeromq как раз не нужен. А вот для обсуждаемой задачки действительно не плохо подходит.
А вот для изобретения http этот самый zeromq вообще идеально вписывается.
Здравствуйте, Iso12, Вы писали:
I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много. I>В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS).
I>Кто что может посоветовать?
Python. Дешево, сердито, многоплатформенно.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
http как раз и позволяет получать те самые пакеты асинхронно, только называются они запросами-ответами. Кто мешает положить в http бинарник ?
Ты говоришь про топологию, а я говорю про протокол. HTTP вообще говоря cпокойно может применяться даже таких вот сетях.
