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

I>Смотрю в сторону GO, Rust и С++.
С практической точки зрения надо выбирать между C++(если скорость очень важна) и JVM. Выгоды от использование двух других языков не будет никакой, а проблем будет вагон и тележка.

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


N>С практической точки зрения надо выбирать между C++(если скорость очень важна) и JVM. Выгоды от использование двух других языков не будет никакой, а проблем будет вагон и тележка.

Какие проблемы?

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


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

Все там нормально делается, UPNP и TCP использует, и UDP, и, внезапно и там и там HTTP

Здравствуйте, 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 не забываем, господа. Там бродкастов нету (и туда им, спамерам, и дорога).

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


I>Мне нужно, чтобы при подключении новой клиентской программы к сервису, все клиенты об этом сразу бы и узнали.

Что то у меня ощущение что ты секретный чатик, убийцу скайпа что ли, пишешь. Чем jabber/xmpp не устраивает? шифрование, бинарные данные, голос, видео, умеет. При подключении клиента "Вася" клиент "Петя" своевременно уведомляется.


Или зачем клиенту знать что к серверу подключился другой клиент? Конкретизируй задачу.

Все проблемы от жадности и глупости

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


I>Это даст готовый протокол, с которым можно делать все что угодно. Кроме бродкаста. Но обнаружение сервисов, клиентов можно и без бродкаста делать.

1)Почему не сделать broadcast, если заранее знать все хосты?
2) На правах теории -- коли время не важно, можно использовать gossip protocol.

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


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. Дешево, сердито, многоплатформенно.