각각 다른 프로그램 2개를 연결하여 실시간으로 데이터를 Read, Write 가능한 방법이 있을까요?

안녕하세요 저는 장비 엔지니어로 일하고 있는 6년차 개발자 입니다.
다름이 아니라 처음으로 부사수가 생겼는데 부사수가 원하는 기능을 꼭 만들어 주고 싶어서 도움을 선배님들께 질문 드리겠습니다.

  1. 구현 이유
  • 장비 프로그램을 지금까지 하나의 솔루션에서 Logic 부분, UI 제어 부분으로 나누어서 구현을 하고 동작 시켰습니다.

하지만 UI에서 문제가 빈번히 발생하는데 이럴 경우 정말 재수 없는 경우 UI가 죽으면 잘 돌고 있는 Logic도 함께 죽는 경우가 발생 합니다.(당연히 하나의 솔루션에 Logic과 UI가 포함 되고 있으니 하나만 죽어도 프로그램이 죽는 건 당연합니다.)

그래서 Logic 프로그램 과 UI 프로그램을 따로 만들어서 UI가 죽어도 Logic은 돌고 있기 때문에 장비의 안전성이 확보 될 것이라고 판단되었습니다.

주위의 다른 회사에서도 Logic따로 UI 따로 하나의 컴퓨터에서 돌리는 방식을 많이 사용하고 있는 것을 확인 했습니다. 그래서 저도 이번 회사에서 꼭 만들어 보고 싶었습니다.

2. 질문
- Logic 프로그램과 UI 프로그램을 각각 다른 솔루션으로 만들어서 구동할 경우, 서로 데이터를 주고 받을려면 어떤 통신 혹은 방법을 사용해야 되는지 솔직히 구글링을 해도 답이 나오지 않아서 질문 드립니다.

  • Logic에서 일어나는 공정관련 변수, 로봇에 관련 된 변수 등이 계속해서 업데이트 될 것 인데, UI 프로그램에서는 Logic의 이러한 데이터들을 어떻게 실시간으로 계속 Reading하고 UI에서 버튼을 클릭 할 경우, 해당 Logic으로 해당 기능을 시작해라 하는 명령을 Write 하는 방법을 솔직히 통신으로 해야되는지 아니면 다른 방법이 있는지 솔직히 잘 모르겠습니다.

★Logic 프로그램 ----------> 실시간 데이터 전달 ----------> UI 프로그램
★Logic 프로그램<---------- UI 프로그램 Logic 동작 명령 <-------UI 프로그램

대표적인 이러한 장비 프로그램인데 도움을 주시면 정말 감사하겠습니다.

3.개발 환경

  1. Winform
  2. .Net6.0
  3. Visual Studio 2022
  4. XML 파일에 Config 데이터 저장
  5. 하나의 PC에서 해당 기능을 구동하고 싶음

이상입니다.

1 Like

이런 경우
MVVM 패턴을 이용합니다
WPF로 구현하시고 예외가 발생하면 모델에서 예외처리를 하시면 됩니다

질문 원문처럼 하실려면
보통 소켓 통신이나 윕소켓 방식으로 할꺼 같습니다
아니면
System.IO.Pipelines 이나 파이프라인으로 해서 검색을 해볼꺼 같습니다…

2 Likes

5년전 소켓으로 분리했을 때 잘 됐습니다. 그땐 프로토콜을 protobuffer로 했어요.

지금 하라면 asp.net core로 http server를 윈도우즈 서비스 만들고 ui는 별도의 프로그램으로 할 거 같네요. (kestral 만세!!! iis 없는 세상!!)

동작 명령은 rest로 만들고 실시간 데이터 전달은 websocket(signalr)로 하면 됩니다.
나중에 웹ui로 갈 수도 있고… 여튼 유연함

5 Likes

감사합니다

공유메모리, 파이프, 소켓 등 방법은 많죠.
추후 n개의 PC로 확장될 가능성도 생각한다면 공유메모리나 파이프보단 소켓이 나을 수 있겠네요

3 Likes

MessageQueue 써보세요

2 Likes

IPC 라고 하고(https://namu.wiki/w/프로세스간%20통신)

일반적으로 소캣을 씁니다.
recv write 쓰레드를 별도로 두시고
UI 접근할때는 beginInvoke 처리 해주시면 됩니다.

3 Likes

@tkm 님 말씀대로 이러한 시나리오라면 NetMQ를 추천합니다. 제시해주신 방식은 Pub/Sub 패턴과 Req/Rep 패턴으로 구현 가능합니다.

image

NetMQ는 몇 가지 장점이 있는데요, 일단 IPC, TCP 같은 전송 방식을 쉽게 사용할 수 있도록 잘 추상화되어 있습니다. 덕분에 어떤 전송 방식을 사용할지 고민할 필요 없고 추후 클라이언트와 서버를 물리적으로 분리하는 것이 쉬워서 확장에 용이합니다.

큰 장점 중 하나는 Connection을 관리해 줄 필요 없이 자동으로 잘 복구해 줍니다. Logic이나 UI 프로세스 중 둘 중 하나가 죽더라도 재실행 시 각 단에서 별도의 처리 없이 연결을 복구해 주고 TCP를 사용하는 원격 구성에서도 마찬가지 이고요.

또한 Stream이 아닌 Frame 단위로 데이터를 전송하기 때문에 원하는 데이터를 끊어서 보내기 용이하고 필요한 Serialization 방식이나 압축 레이어 등을 구현하기 용이합니다. async/await 패턴도 당연히 지원하기 때문에 비동기 작업을 쉽게 구현할 수 있습니다.

GitHub - zeromq/netmq: A 100% native C# implementation of ZeroMQ for .NET

NetMQ: Efficient Inter-Process Communication - DEV Community

5 Likes

좋은 의견 감사합니다.

NETMQ 는 GNU GPL 3 라이선스 던데 이것은 혼자 사용 할거라면 문제 없지만
기업 에서 사용자 들 한테 배포 할거 라면 소스코드 공개 의무가 있지 않나요 ?

LGPL(GNU Lesser General Public License)이라 NETMQ를 사용하는 소프트웨어 자체의 소스코드 공개 의무는 없는 것으로 알고 있습니다.

LGPL 이군요…

소스 공개 의무는 없네요… 다만

사용자가 라이브러리를 교체할 수 있는 방법을 제공 해야 한다는데… 이 부분은 어떻게 피해가죠 ?

동적으로 참조 하면 해결 되려나요

네. 일반적으로 뉴겟 패키지 DLL 형태로 참조하기 때문에 문제가 없을 것 같습니다.