Добрый день,

Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.
В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS).
Смотрю в сторону GO, Rust и С++.

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

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

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

Я бы выбрал 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>Кто что может посоветовать?

Perl и PHP

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

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

I>Нужно реализовать сетевой сервис, данные пакуются в TCP и UDP пакеты и пересылаются по сети. Данных не много.
I>В общем обыкновенная реализация сервера и клиента, но нужно реализовать кросплатформенно (Windows Linux, macOS).
I>Смотрю в сторону GO, Rust и С++.

I>Кто что может посоветовать?
Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.

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


Pzz>Я бы выбрал Go
Почему?

Здравствуйте, Географ, Вы писали:

Г>Java сработает один раз для всех. Пересобирать не придётся.

В будущем планируется использовать и на Embedded Linux. Поэтому не хотелось бы везде таскать с собой JVM.

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


G>Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.

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

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

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


G>>Могу посоветовать не заниматься этим, а воспользоваться готовым сервером. В вашем случае поможет netcat. Приложение должно просто писать данные в нужном формате в стандартный вывод.

I>Программа должна иметь свою не простую логику со множеством соединений и запускаться как сервис.
В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать?
Если реагировать не надо, то netcat подойдет.

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

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

Какие языки и API знаете?

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

Pzz>>Я бы выбрал Go
I>Почему?

Ну, поскольку данных не очень много, то производительность значения не имеет (Go не то, чтобы совсем уж тормоз, но раза в два Си, а значит, C++ и Русту, проигрывает).

С другой стороны, ты просил кроссплатформенность. С ней у Go очень хорошо. Программу типа сетевого сервиса можно собрать из одних и тех же исходников, и если не надо чего-то очень уж экзотического, то никакого ветвления (ни на этапе компиляции, не во время исполнения) в зависимости от операционной системы вообще не потребуется. Кроме того, стандартная библиотека Go очень практична, и для програм такого плана в ней есть все, что нужно.

Кроме того, у Go очень хорошо налажена кросс-компиляция. Не является проблемой сидя на одной из перечисленных платформ собирать программу под все остальные. Что довольно удобно, попробуй-ка сделать автоматизированный билд на N платформ, если для его реализации потребуется скоординированная работа N компьютеров, каждый под своей операционной системой.

И наконец, если писать на чистом Go (без использования сторонних сишных библиотек), на выходе получается статически собранный исполняемый файл, у которого вообще нет внешних зависимостей. Распостранять такие програмки — одно удовольствие.

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

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

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


G>В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать?
G>Если реагировать не надо, то netcat подойдет.
Да, должна принимать, реагировать и отправлять дальше другим клиентам.

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

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


G>>В итоге программа что-то шлет в сокет? Или еще принимать что-то должна и както реагировать?
G>>Если реагировать не надо, то netcat подойдет.
I>Да, должна принимать, реагировать и отправлять дальше другим клиентам.

http не проще будет?

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

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

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

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

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

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

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

А какие еще требования и ограничения есть ? Нагрузка, скорость передачи, количество клиентов, задержки всякие и тд и тд. И что значит "обмениваться между собой" Если начать с UDP большой шанс, что изобретешь TCP. А начав с TCP можно легко изорбрести HTTP

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


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), так и что-то иное.