Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / C++ Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Ну и что?

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?
23 май 20, 18:32    [22138258]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
mayton
пропущено...

Ну и что?

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?

Нет я считаю что инженерия знаний - это поиск и исопльзование. Если ты нашел что-то и оно решает
твою задачу в разумные сроки - это успех.

Если из принципа не подключать зависимости к коду (дескыть я и сам напишу) - то такой путь
предполагает что ты напишешь сам вообще все. И драйвер к БД. И рендерер 3Д графики.
Можно и Буст написать.

Вобщем граница здесь - зыбкая. Я не осуждаю. Не хотите - не используйте. Но эволюционный
процесс - предполагает предпочтение повторного использования изобретению.
23 май 20, 18:40    [22138261]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

mayton
Если ты нашел что-то и оно решает твою задачу в разумные сроки - это успех.

А если нашёл что-то, что решает не совсем твою задачу или не совсем её решает? Вот как у
топикстартера, например.

Posted via ActualForum NNTP Server 1.5

23 май 20, 18:43    [22138263]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Protobuf - все решит.
23 май 20, 18:48    [22138265]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 50033

А если решит не всё, надо найти ещё одну библиотеку, которая в сочетании с ним решит
недостающее. Это Ява-ой-вэй.

Posted via ActualForum NNTP Server 1.5

23 май 20, 18:50    [22138266]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

Да ничего, нормально всё. Добавляйте. Только не понятно зачем задавать бессмысленные вопросы? Или вам снова процитировать разработчика PVS Studio?

Нет я считаю что инженерия знаний - это поиск и исопльзование. Если ты нашел что-то и оно решает
твою задачу в разумные сроки - это успех.

Если из принципа не подключать зависимости к коду (дескыть я и сам напишу) - то такой путь
предполагает что ты напишешь сам вообще все. И драйвер к БД. И рендерер 3Д графики.
Можно и Буст написать.

Я где-то призывал не использовать сторонние библиотеки? Да ерунда, не было такого. Вы манипулируете.

mayton
Вобщем граница здесь - зыбкая. Я не осуждаю. Не хотите - не используйте. Но эволюционный
процесс - предполагает предпочтение повторного использования изобретению.

Нет, эволюция как раз и есть квинтэссенция изобретения.
23 май 20, 18:50    [22138267]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
Dimitry Sibiryakov

А если решит не всё, надо найти ещё одну библиотеку, которая в сочетании с ним решит
недостающее. Это Ява-ой-вэй.

На этом форуме явно не хватает функции лайков. :) Лайк!
23 май 20, 18:53    [22138269]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
Нет, эволюция как раз и есть квинтэссенция изобретения.

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?
23 май 20, 18:53    [22138270]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav

Я где-то призывал не использовать сторонние библиотеки? Да ерунда, не было такого. Вы манипулируете.

Тогда прошу прощения. Это направление дискуссии закрыто.
23 май 20, 18:54    [22138271]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
petrav
Я где-то призывал не использовать сторонние библиотеки?

Только те, которые Гугл "тянет"?
23 май 20, 18:58    [22138273]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
Нет, эволюция как раз и есть квинтэссенция изобретения.

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?

Я, конечно, готов обсуждать банальные вещи, потому что часто нам вещь кажется банальной. Но на практике она оказывается очень сложной, хотя и выгладят простой с первого взгляда. Но в таком случае и вопрос должен намекать на какие-то неординарные моменты. А ваш вопрос банален. Не вижу смысла на него отвечать по сути.
23 май 20, 19:04    [22138279]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
"стакан полу налитый или полупустой"? )))
Я выше про функционал говорил к такому примеру.
Если потребуется отправить команду - метод по IP на другую машину то qRPC решит задачу.
А DBus не решит.
Это как пример функционала.
Надо это или нет решает руководство.
23 май 20, 19:04    [22138281]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
PetroNotC Sharp
"стакан полу налитый или полупустой"? )))
Я выше про функционал говорил к такому примеру.
Если потребуется отправить команду - метод по IP на другую машину то qRPC решит задачу.
А DBus не решит.
Это как пример функционала.
Надо это или нет решает руководство.


Тут еще тонкий момент. Есть взаимодействие типа посылка месседжей (MQ). И есть - вызов методов (RPC).
Они похожи но первый асинхронный и практически без обратной связи. Тоесть контролируется просто
факт доставки хотя-бы одному потребителю. Работает очень быстро. А что дальше с сообщением
случилось на прикладном уровне? Обработано оно или у тебя был division by zero... ХЗ. Это уже
не задачи MQ. Это уже прикладной слой.

И второе взаимодействие - дёрнул метод (RPC) и получил код ошибки. Работает
медленно. Но надежно. Каждая интеракция между процессами имеет фиксацию.
Ты точно знаешь что получил ответ.

ZeroMQ, DBus - это про первое. Это стрим месседжей.

Любая библиотечка Rest/SOAP/Http - это второе.

И protoBuf - это ни первое и не второе а просто протокол сериализации-десериализации объекта в БЛОБ.
Причем такой блоб которому пофиг на разрядность int, и пофиг на порядок байтов в слове (BigEndian).
И более того. ProtoBuf может подружить между собой например C++/JavaScript и все остальное.

Мы используем протобуф не напрямую а косвенно как Apache-ORC - формат документа для биг-дата
где десятки терабайт таблиц упаковываются в такие-себе Vertical Arrays. И со сжатием ZLib/Snappy
уже поверх данных и завернутых в proto.

А какие усилия сишник потратит для поддержки вот такой кросс-платформенности на основе структур
struct? Я не знаю. Опять-же чтоб прочувствовать преимущества прото-буф - надо чтобы оба процесса
были на разных архитектурах.

А если у тебя процессы - гомогенные (оба под Win32 и одной разрядности) то наверное протобуф
тебе и не нужен.
23 май 20, 19:54    [22138298]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav
mayton
пропущено...

Давай отвлечемся. Как ты думаешь? Зачем было созданое "наследование" как один из пунктов идеологии ООП?

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


С тобой иногда бывает так сложно говорить. Вот ты сказал первый свою банальность дескыть:

>> Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Это - банальность. Знаешь я не помню в каком бизнес-сегменте ты работешь. Кажется что-то с авиацией
или АСУТП. Но мне кажется что у тебя есть определённая проф-деформация.

Я всегда старался из себя эту деформацию изгонять. Смотреть на мир широко отрытыми глазами
и не позволять предвзятости брать верх.

У тебя есть элемент предвзятости. Ты сослался на PVS-Studio? Ты что? Cотрудник этой организации?
Зачем вообще нам в дискуссию затаскивать это? Неужели у нас нет аргументов кроме какого-то кастомного
приложения которое создавалось чтоб стыдливо закрыть дефекты 40 летней эволюции кодирования на С++?

Сообщение было отредактировано: 23 май 20, 20:27
23 май 20, 20:00    [22138301]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
mayton
Есть взаимодействие типа посылка месседжей (MQ).

конечно, в данном топике message-oriented middleware мы не рассматриваем.
Все просто - getName() из другого процесса\демона
23 май 20, 20:09    [22138310]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton

А какие усилия сишник потратит для поддержки вот такой кросс-платформенности на основе структур
struct? Я не знаю. Опять-же чтоб прочувствовать преимущества прото-буф - надо чтобы оба процесса
были на разных архитектурах.

На самом деле обмен структурами Human, Car, Dog... причём в произвольном порядке в канале данных. Это весит, ну максимум 500 строчек кода. С проверкой контрольной суммы, с анализом возможных шумов в канале данных. Причём взаимодействие на разных архитектурах.
23 май 20, 20:33    [22138315]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav
Это весит, ну максимум 500 строчек кода.

какого уровня программиста и сколько будет в баксах потеря компании если там баги?
Вот пример на java простейшего сервера для школы.
Они есть готовые
---------
import java.io.DataInputStream;
import java.io.DataOutputStream;
import java.io.IOException;
import java.net.ServerSocket;
import java.net.Socket;

public class TestAsServer {

/**
 * 
 * @param args
 * @throws InterruptedException
 */
    public static void main(String[] args) throws InterruptedException {
//  стартуем сервер на порту 3345

        try (ServerSocket server= new ServerSocket(3345)){
// становимся в ожидание подключения к сокету под именем - "client" на серверной стороне                                
                Socket client = server.accept();

// после хэндшейкинга сервер ассоциирует подключающегося клиента с этим сокетом-соединением             
                System.out.print("Connection accepted.");

// инициируем каналы для  общения в сокете, для сервера     

// канал записи в сокет
                DataOutputStream out = new DataOutputStream(client.getOutputStream());
                System.out.println("DataOutputStream  created");

                // канал чтения из сокета
                DataInputStream in = new DataInputStream(client.getInputStream());
                System.out.println("DataInputStream created");

// начинаем диалог с подключенным клиентом в цикле, пока сокет не закрыт                
                while(!client.isClosed()){

                System.out.println("Server reading from channel");

// сервер ждёт в канале чтения (inputstream) получения данных клиента               
                String entry = in.readUTF();

// после получения данных считывает их              
                System.out.println("READ from client message - "+entry);

// и выводит в консоль              
                System.out.println("Server try writing to channel");

// инициализация проверки условия продолжения работы с клиентом по этому сокету по кодовому слову       - quit  
                if(entry.equalsIgnoreCase("quit")){
                    System.out.println("Client initialize connections suicide ...");
                    out.writeUTF("Server reply - "+entry + " - OK");    
                            out.flush();
                    Thread.sleep(3000);
                    break;
                }

// если условие окончания работы не верно - продолжаем работу - отправляем эхо-ответ  обратно клиенту               
                out.writeUTF("Server reply - "+entry + " - OK");                
                System.out.println("Server Wrote message to client.");

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

                }

// если условие выхода - верно выключаем соединения             
                System.out.println("Client disconnected");
                System.out.println("Closing connections & channels.");

                // закрываем сначала каналы сокета !
                in.close();
                out.close();

                // потом закрываем сам сокет общения на стороне сервера!
                client.close();

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

                System.out.println("Closing connections & channels - DONE.");
            } catch (IOException e) {
                e.printStackTrace();
        }
    }
}
23 май 20, 20:41    [22138319]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
petrav,
а шумы в канале откуда?
23 май 20, 20:43    [22138321]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
petrav
Member

Откуда:
Сообщений: 2105
mayton
petrav
пропущено...

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

С тобой иногда бывает так сложно говорить.

У всех свои недостатки, я прошу прощения.

mayton
Вот ты сказал первый свою банальность дескыть:

>> Тем что Qt у тебя уже есть, а добавляя ещё одну библиотеку — ты добавляешь новую зависимость.

Это - банальность.

Конечно, это банальность. Но я не задавал банальных вопросов. А вы, mayton, задали именно что банальные вопросы. При этом вы высококвалифицированный программмист.

mayton
Знаешь я не помню в каком бизнес-сегменте ты работешь. Кажется что-то с авиацией
или АСУТП.

Нет.

mayton
Но мне кажется что у тебя есть определённая проф-деформация.

Конечно, как и у вас.

mayton
Я всегда старался из себя эту деформацию изгонять. Смотреть на мир широко отрытыми глазами
и не позволять предвзятости брать верх.

Это пример для подражания.

mayton
У тебя есть элемент предвзятости. Ты сослался на PVS-Studio? Ты что? Cотрудник этой организации?

Нет, я не сотрудник этой компании. Да, у меня есть элемент предвзятости, но эта предвзятость основана на боевом опыте и на статьях, которые они пишут. Я просто их уважаю и понимаю.

mayton
Зачем вообще нам в дискуссию затаскивать это? Неужели у нас нет аргументов кроме какого-то кастомного
приложения которое создавалось чтоб стыдливо закрыть дефекты 40 летней эволюции кодирования на С++?

?! Хватит говорить ерунду.
23 май 20, 21:00    [22138322]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
Нет. Сокет-сервер - это слишком примитивно. Автору нужен API для
синхронных интеракций. Например на базе Http.

Давайте на верхнем архитектурном уровне
нарисуем этот API как абстракции. А потом имплементируем.

interface IPetroServer {
        
}

Почему я хочу именно в таком виде. Чтобы отвязаться от всяких Human, Car, Doc
и от разговоров ниочем.
23 май 20, 21:04    [22138324]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
mayton
Member

Откуда: loopback
Сообщений: 46496
petrav, давай возьмем паузу на недельку. Просто мы напрягаем
общество банальностями и перебранкой.
23 май 20, 21:07    [22138327]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
mayton
Автору нужен API для
синхронных интеракций. Например на базе Http.

Например, ZeroMQ с парой штатный zmq сокетов req-rep.
23 май 20, 21:09    [22138328]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
ъъъъъ
mayton
Автору нужен API для
синхронных интеракций. Например на базе Http.

Например, ZeroMQ с парой штатных zmq сокетов req-rep.
23 май 20, 21:09    [22138329]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
PetroNotC Sharp
Member

Откуда:
Сообщений: 4785
ъъъъъ,
ну дак, для кругозора и альтернативы надо ещё знать одну - две либы.
Чтобы выбирать то было из чего.
23 май 20, 21:23    [22138334]     Ответить | Цитировать Сообщить модератору
 Re: Что выбрать для межпроцессного взаимодействия модулей приложений?  [new]
ъъъъъ
Member

Откуда:
Сообщений: 685
PetroNotC Sharp,

это же прикольно.
23 май 20, 21:42    [22138341]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6   вперед  Ctrl      все
Все форумы / C++ Ответить