프로젝트 기획중인데 가능성 여부 또는 제안을 받아보고 싶습니다.

어지러버 · 6월 4, 2024, 11:19오전

안녕하세요.
닷넷에 입문한지 이제 서너달 된 초보자 입니다.
현재 큰 프로젝트를 계획 중에 있는데, 이론상으로 조합해본 제 구상이 맞는지 문의 드리려 합니다.
가능성 여부 또는 더 나은 제안이 있는지 가감없이 말씀해 주시면 감사하겠습니다.

현재 여러 대의 하드웨어 장비가 TCP 프로토콜로 서버와 통신을 하고 있는데요.
이전에는 윈폼으로 만든 서버였는데 이제 WPF로 교체하려 합니다.
프로토콜도 바뀐것도 있고, .net의 버전이 상향됨에 따라 교체가 필수 입니다.

그리고, 각종 장비로 부터 오는 데이터를 가공해서 웹으로도 보여주어야 합니다.
마지막으로 웹에서 장비로 별도의 명령도 보낼 수 있어야 합니다.
전체적으로 3 tier 급인데 도식화 하면 아래와 같습니다.

문의 드리고자 하는건

위 구상대로 데스크톱앱을 통해 raw 데이터를 받아 가공해서 블레이저 서버에 signalR로 전달하고, 블레이저 서버는 또 signalR 로 클라이언트에게 보내는게 효율적일까 하는 겁니다.
블레이저 서버가 signalR을 통신하기 위해 서버와 클라이언트 기능 두개를 탑재해야 하는것 같아서요.
만약 wpf를 빼버린다 하면 블레이저 서버가 장비로 부터 오는 raw데이터를 어떤 방법으로 받을 수 있는지요? 웹은 문외한이라… 감히 여쭤봅니다.
이 말고 더 좋은 방법은 없는지도 궁금합니다.

이론만 봐선 다~~~~ 될것 같은데, 고수들의 경험치가 더 중요해 보이는 시점이네요.

밀수나라 · 6월 4, 2024, 1:37오후

현재 서버라고 만들어놓은게 일부러 ui에 백그라운드로 소켓서버 띄워서 할려고 그렇게 만들어 놓은것 같은데…

서버는 윈폼이든 wpf든 그 문제는 아닙니다. 어차피 그 서버는 소켓 열어서 데이터 받아서 DB에 데이터 저장용이 되는거죠.
굳이 wpf로 바꿀 필요는 없습니다.

현재 .net에서 지원하는 api 서버가 소켓을 열어서 데이터를 받을 수 있습니다.
그렇기 때문에 api서버로 하셔도 됩니다. 그리고 api서버와 블레이저 서버가 붙어도 되구요.

하드웨어 장비라는거보니 공장쪽이신거 같아서 제가 더이상은 자세한 스펙을 몰라서 설명드리기는 애매합니다.

만약 붙는 장비가 갯수가 얼마 없다면 블레이저 서버에 소켓을 열어서 해도 되긴 하겠지만… 만약을 위해서 그건 조금 분리하는게 좋긴 하겠죠.

즉, wpf 라고 해놓은곳 → api서버에서 소켓열어서 tcp연결하고 블레이저 서버랑 시그널r 연결 처리 하면 다른거는 뭐 모르겠네요

그라목손 · 6월 4, 2024, 1:39오후

일반적으로 서버는 윈도우 서비스로 만듭니다.

어지러버 · 6월 4, 2024, 3:23오후

답신 남겨주셔서 감사합니다
wpf를 만드는 이유는 우선 웹 서버가 구동되기 전단에서, 장비들이 잘 연결되었는지 또는 통신 장애는 없는지 엔지니어 의 모니터링이 목적이라 로그뷰어 및 트래픽 감시를 위해 ui가 필요해서 입니다.
장비는 200여대 정도 되는데 트래픽이 좀 많습니다. 그래서 웹과는 분리를 하는게 좋겠다 여겼습니다
그걸 포기한다면 오로지 웹에서 다 보여줘야 하는데, 그럴려면 답글 주신것처럼 api 서버에 소켓을 열어서 장비랑 통신하고 가공된 정보를 블레이저 서버로 보내야 하겠네요. 이때 클라이언트 역할로 해야할까요? 아니면 서버역할로 해야 할까요?

Wonkyoung_Lee · 6월 4, 2024, 5:13오후

이 질문에 대한 답은 장비에 따라 다르지 않을까요?
서버든 클라이언트든 장비가 제공하는 프로토콜을 따라야할 것 같은데요.
만약에 트래픽이 많고 로그, 관리가 어렵다면, PLC나 OPC 서버 등을 이용하는 것도 방법이라고 생각합니다.

어지러버 · 6월 4, 2024, 11:10오후

답신 주셔서 감사합니다. 좋은 제안이시긴 합니다만, 여태 잘 사용하던 윈폼앱이 있었기에…그 부분은 미고려 대상입니다. ^^;;

dimohy · 6월 5, 2024, 2:07오전

질문의 요지는 모니터링(및 제어) 파트에 실시간 정보를 주거나 장비 또는 장비 정보 수집기를 제어하기 위해 어떤 기술을 써야 하는가 인 것 같네요.

Blazor는 웹 앱 기술입니다. 원하는 기능을 제공하기 위해 직접적으로 필요하지는 않습니다. 어떤 RPC 기술을 사용해서 실시간 정보를 양방향으로 주고 받을 수 있는지 살펴보시면 될 것 같습니다.
예) SignalR, gRPC, …
SignalR 서버는 Web Server에만 있으면 됩니다. (첨부된 도식 참고) Device Data Receiver 및 Client는 SignalR 클라이언트가 됩니다.
WPF를 뺀다는 의미는 Device Data Receiver와 Monitoring/Controls를 하나로 통합한다는 의미입니다. 이것은 장비의 프로토콜 사양에 의존적이기 때문에 그쪽에 맞게 구현해야 합니다. 가령 TCP/IP의 자체 프로토콜이라면 별도의 TCP/IP 리스너를 구현해야 합니다.

신현뚜벅 · 6월 5, 2024, 2:13오전

저라면 2가지 방법이 있겠습니다.

블레이저 서버만 둡니다. 기존 윈폼이 담당하면 UI를 블레이저로 구현하여 웹페이지로 보는 것이지요. 서버에 기존 윈폼이 담당하던 소켓서버역할도 구현하고요. 그러면 웹페이지의 유저액션에 따라 장비에 패킷을 보내야할 때 구현한 소켓서버역할에서 바로 보내면 되겠지요.
그런데 1번처럼하면 UI 변경같은 것 때문에 재배포시에 소켓서버도 잠깐 내려져야할 겁니다. 그 사이에 DB에 저장되어야할 값이 있을 시나리오라면 분리를 해야겠지요. 질문자님 그림처럼요. 이 상황에서 블레이저서버가 wpf에 보내는 신호는 signalr이 아니라 그냥 소켓통신을 하면 될 것 같습니다.

BigSquare · 6월 5, 2024, 5:55오전

만약 로드가 그렇게 높지 않다면 아래와 같이 간소한 구조도 고려해 볼 수 있습니다.

WAS (MVC, 웹앱, 블레이저 웹앱) 는 웹 UI 를 제공하기에 localhost, 인트라넷, 혹은 인터넷으로 접근이 가능합니다.

데이터 업로드는 WAS와 함께 돌고 있는 IHostedService 가 처리합니다.

class DataUploader : IHostedService

// 간편 객체
// class DataUploader : BackgroundService

디바이스 관리는

class DeviceManagerTcp : IDeviceManager

이 객체는 요청 핸들러가 사용합니다.

MVC - Controller,
Web App - Page,
Blazor - Component

단기적 확장은 PC의 성능 업그레이드(CPU, RAM)를 통해, 장기적 확장은 WAS 의 추가, 리버스 프록시 추가를 통해 대응할 수 있습니다.

어지러버 · 6월 5, 2024, 8:48오전

답신 남겨주신 모든 분들께 감사드립니다.
주~욱 글을 읽다보니 미처 말씀 못드린 부분도 있는것 같아 한두가지 첨언하려고 합니다.

우선 웹서버 앞에 장비랑 통신하는 전용 앱을 두려는 이유는, "신현뚜벅"님 말씀처럼 웹서버를 잠시라도 다운시켜야 할 경우가 생기거나, 또는 가공할 정보의 수정이 생길경우 웹서버까지 지장을 안주게 하기 위함이 큽니다.
그 밖에 장비 전용 로그도 남겨야 할 것 같고, 장비와의 하트비트 같은 폴링 신호는 굳이 웹서버에게 부담을 주고싶지는 않았거든요. 그래서 필수 앱으로 보고 있습니다.

wpf를 쓰는 이유는 일단, 고객이 원하는 바가 큽니다. ㅠㅠ
비쥬얼틱한 대시보드를 원하네요.
웹에서도 되는거지만, 실시간 트래픽 관련 정보를 굳이 웹까지 끌고 갈 필요는 없을것 같습니다.

여튼 이 두가지 사항이 가장 커서 wpf를 사용하는 건데, 문제는 가공된 정보를 블레이저 서버로 주고 받고 해야 하는 건이 많이 궁금했습니다.
권고하는 signalR을 쓰는게 맞는지 소켓통신을 하는게 맞는건지 아니면 다른 좋은방법이 있는지 말이죠. 장비로 부터 오는 모든 정보를 걸러서 필요한 데이터만 실시간 급으로 웹서버로 보내려는데 찾아본 바로는 signalR 이 제격으로 보였습니다.

아~~ 이게 글로 쓰려니 답답한 부분이 있긴한데, 여튼 주요 부분은 위 설명과 같습니다.
그나저나 이렇게 적극적으로 글 남겨 주셔서 다시한번 감사드립니다.

어지러버 · 6월 5, 2024, 8:49오전

이 부분은 꼭 참고하겠습니다. ^^

BigSquare · 6월 5, 2024, 9:32오전

사실 원래는 아래와 같은 시스템을 제안하려고 했습니다.

메시지 라인(웹소켓)과 데이터 라인(Http)이 분리된 구조입니다.
(SignalR 은 Web Socket 에 기반합니다)

참고로, 통신 모듈은 장비 관리 모듈에 편입될 수 있습니다.

또한, WPF 앱의 주 스레드의 임무는 UI의 업데이트입니다. 이 앱 입장에서는 데이터 업로드는 부속 임무가 될 수 밖에 없습니다.

웹서버에 요청의 처리 및 렌더링 외에 다른 부담을 주지 않으려 하듯, 데이터 업로드도 다른 부담(UI 업데이트)을 떠 안으면 안되겠죠.

많은 분들이 WPF 자리에 비 UI 앱을 넣은 이유이기도 합니다.
위 제안에서, 웹 클라이언트 자리에 WPF가 들어 갈 수는 있습니다.

어지러버 · 6월 5, 2024, 10:27오전

제안 주셔서 감사합니다. 감이 좀 잡혀지는것 같긴합니다.
우선 저로서는 비UI 앱으로 대체하는게 큰 변화겠네요.
이 부분은 고객 설득을 진행해 봐야 할 것 같구요.
웹 서버가 다운되어도 안정적으로 데이터는 수집할 수 있어야 하는데 그 부분이 없어서 좀 맘에 걸리네요. 고민해 봐야 할 것 같아요.

BigSquare · 6월 5, 2024, 10:51오전

그 부분을 위해, 통신 모듈에 DB(SQLite)를 존재하는 것입니다.
API Post 에러가 발생하면, SignalR 서버로 전송하고, 이를 DB에 임시 저장하는 것이죠.

API가 복구되면, bulk insertion 을 수행해야 하는데, 그 부분이 SignalR 에서 API로의 검은 색 점선입니다.

어지러버 · 6월 5, 2024, 10:55오전

오홋…감사합니다. ^^