Когда мне следует использовать Pipes или gRPC для межпроцессного взаимодействия (в C # .NET Core)?

Как Pipes, так и поддержка gRPC ASP.NET Core локальный и удаленный IPC / RPC (с некоторыми ограничениями платформы для gRPC)

Когда я буду использовать одну технологию (Pipes) или другую (gRPC)?

Я имею в виду наблюдения, мысли и соображения:

  • gRPC, похоже, ориентирован на замену WCF в какой-то будущей итерации.

  • локальные развертывания и с машинными ограничениями (работа без прав администратора / пользователя, машинные брандмауэры, разные платформы / ОС)

  • обход сети и совместимость с одной машиной - ›несколько машин (массивы внешнего / внутреннего интерфейса) для загрузки и расширения

  • Расширение безопасных зон (где используется прокси или другой параметр шифрования / порядка / реестра TLS) влияет на возможность работы HTTP / 2

  • Каналы (именованные каналы?) Имеют разную площадь поверхности и порт (они также используют порт 135 или NetBIOS через TCP (не уверен в названии)) ... как это сканируется и защищается?

  • Файлы с отображением памяти кажутся проблемой для работы, однако, похоже, они работают в ASP.NET Core с gRPC в конфигурации UDS. Это правильный вывод?

Прямо сейчас мой сценарий состоит в том, чтобы два консольных приложения взаимодействовали друг с другом, на одном компьютере или удаленном. Добавление Asp.NET Core Web - это дополнительная альтернатива внешнего интерфейса для моего сценария.


grpc c# asp.net-core-5.0 ipc named-pipes
person TLDR    schedule 07.12.2020    source источник
comment
Удаленные именованные каналы: просто скажите «нет». Вы не захотите ложиться спать с NetBIOS, если сможете. Локальные именованные каналы хороши, но дают небольшое преимущество перед локальным TCP-соединением, если вы все равно собираетесь разрешать / требовать удаленные сценарии. Если все коммуникации будут строго локальными, их будет сложно превзойти с точки зрения скорости (разделяемую память можно, но гораздо сложнее запрограммировать, по крайней мере, в Windows).   -  person Jeroen Mostert    schedule 07.12.2020
comment
@JeroenMostert - это это с использованием общего память, или это общая блокировка файла?   -  person TLDR    schedule 07.12.2020
comment
Мне также неясно, приравниваются ли указанные выше каналы к NetBIOS. Будет ли это также означать, что он может распространиться на систему именования WINS, или может? Просто пытаюсь увидеть полную картину.   -  person TLDR    schedule 07.12.2020
comment
gRPC - это HTTP с определенной полезной нагрузкой, поэтому ваш вопрос становится Should I use pipes or HTTP?   -  person Panagiotis Kanavos    schedule 07.12.2020
comment
какие ограничения платформы для gRPC?   -  person Markus Dresch    schedule 07.12.2020
comment
@MarkusDresch (MacOS, AppService) docs.microsoft .com / en-us / aspnet / core / grpc /   -  person TLDR    schedule 07.12.2020
comment
@TLDR: доменные сокеты не являются разделяемой памятью, они реализованы в ядре как отдельный драйвер (как и именованные каналы). Конечно, именованные каналы и доменные сокеты и локальные TCP-сокеты технически сводятся к некоторой форме совместного использования памяти под покровом, поскольку данные никогда не покидают машину, а только представления с отображением памяти поверх сопоставлений файлов правильная разделяемая память. (Несмотря на отображение имени файла, если файл поддерживается системой подкачки, не требуется доступа к диску, поэтому ни одна из этих вещей на самом деле не использует файлы.)   -  person Jeroen Mostert    schedule 07.12.2020
comment
Именованные каналы сами по себе не используют NetBIOS, но протоколы для удаленной связи по именованным каналам построены на NetBIOS. Проблемы NetBIOS многочисленны и разнообразны - производительность и безопасность никогда не были краеугольными камнями. Удаленные именованные каналы просто непривлекательны для любого современного приложения - они непереносимы, не масштабируемы, небезопасны по умолчанию. У локальных именованных каналов нет этой проблемы, но они только для Windows, поэтому был добавлен UDS, обслуживающий тот же сценарий, но переносимый. Только TCP или для специализированных сценариев UDP действительно заслуживают внимания для удаленных подключений.   -  person Jeroen Mostert    schedule 07.12.2020
comment
Спасибо @JeroenMostert   -  person TLDR    schedule 08.12.2020

Ответы (1)


arrow_upward
1
arrow_downward

Простой IPC

Зависит от того, сколько будет общения. Если ваше общение ограничивается простой совместной передачей сигналов или обменом некоторыми данными между двумя процессами, вы можете безопасно использовать NamedPipeClientStream и NamedPipeServerStream в локальной системе или в локальной сети, но если вы планируете то же самое в разных системах, я бы предложил использовать TcpClient и TcpListener.

Комплексный IPC

WCF или теперь его замена gRPC предназначен для сценария, когда полный API / Framework необходимо выполнять удаленно. Например, у меня есть целая библиотека классов, которые мне нужно вызвать из другого процесса (который в основном выполняется в другой системе); в этом случае решения типа gRPC имеют больше смысла.

Решать можете только вы.

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

person Ashutosh Raghuwanshi    schedule 07.12.2020
comment
Спасибо. Как / где вы бы рассмотрели API-интерфейсы SignalR, Websockets или REST в отличие от способа работы IPC? - person TLDR; 07.12.2020
comment
API-интерфейсы @TLDR REST могут быть такими же всеобъемлющими для веб-приложений, как и gRPC в целом. WebSocket - это очень низкоуровневый API для Интернета, а SignalR - это удобный уровень над WebSockets, но все же его следует использовать для довольно простых коммуникаций. - person Ashutosh Raghuwanshi; 07.12.2020