다중 시스템에서 그래픽 표시를 실행하여 동기화를 유지합니다

Question

동기화 된 디스플레이 루틴을 실행하는 LAN에 일련의 시스템이 있습니다. 예를 들어 코러스 라인을 생각해보십시오. 그들이 실행 한 프로그램은 고정되어 있습니다. 각 "클라이언트"전체 루틴을 다운로드 한 다음 동기화를 위해 루틴의 고정 지점에서 중앙 "서버"에 문의하십시오. 일상 자체는 아마도 20 가지 가능한 지침으로 평범합니다.

각 클라이언트는 동일한 루틴을 실행하지만 한 번에 완전히 다른 일을 할 수 있습니다. 코러스 라인의 한 부분은 왼쪽으로 차고 다른 부분은 오른쪽으로 차고 있지만 항상 서로 시간이 지남에 따라 있습니다. 클라이언트는 언제든지 가입하고 중단 할 수 있지만 모두 부품을 할당했습니다. 아무도 부품을 실행할 사람이 없다면, 그것은 단지 실행되지 않습니다.

이것은 모두 C# .NET로 코딩됩니다.

클라이언트 디스플레이는 Windows Forms 응용 프로그램입니다. 서버는 TCP 연결을 수락 한 다음 라운드 로빈 패션에 서비스를 제공하여 진행중인 작업의 마스터 시계를 유지합니다. 클라이언트는 "I 's Sync-Point 32에 도달했습니다"(또는 19, 5 또는 무엇이든)라는 신호를 보내고 서버가 승인 한 다음 이동을 기다립니다. 또는 서버는 "아니오, Sync-Point 15에서 시작해야합니다"라고 말할 수 있습니다.

이 모든 것이 잘 작동합니다. 이있다 미성년자 첫 번째와 마지막 클라이언트 사이의 약간의 지연이 동기화 지점에 도달했지만 눈에 띄지 않습니다. 몇 달 동안 달렸습니다.

그런 다음 사양이 변경되었습니다.

이제 고객은 서버에서 거의 실시간 지침에 응답해야합니다. 더 이상 사전 설정 댄스 프로그램이 아닙니다. 서버는 지침을 보내고 댄스 프로그램이 즉석에서 구성됩니다. 프로토콜, 서비스 루프 및 프로그래밍 지침을 다시 디자인하는 재미있는 작업을 얻습니다.

내 툴킷에는 표준 .NET 3.5 도구 상자에 모든 것이 포함되어 있습니다. 많은 시스템 (클라이언트)이 참여할 수 있기 때문에 새로운 소프트웨어를 설치하는 것은 엉덩이의 고통입니다.

나는 클라이언트를 동기화하는 (일종의 래칭 시스템? UDP? 방송?), "댄스 프로그램"의 배포에 대한 제안을 찾고 있습니다.

시간/속도 제한도 진행되고 있음을 명심하십시오. 나는 댄스 프로그램을 네트워크 데이터베이스에 넣을 수 있었지만 상당히 빠르게 지침을 밀어야하고 다소 두꺼운 프로토콜 (DBI, SQLClient 등)을 사용하여 많은 독자가있을 것입니다. 텍스트의. 지나치게 복잡해 보입니다. 그리고 나 아직 동기화로 표시 할 수있는 것이 필요합니다.

제안? 의견? 야생의 추측? 코드 예?

추신 : 답변은 "올바른"로 표시되지 않을 수 있습니다 (이것은 "올바른"답변이 아니기 때문에). +1은 좋은 제안을 위해 투표합니다.

Answer 1

나는 단일 시스템에 의해 실행되며 중앙 서버에서 메시지를 수신하는 4 개의 디스플레이 뱅크를 동기화하는 비슷한 (꽤 오래)를 수행했습니다.

우리가 마침내 하나의 "마스터"기계를 갖는 것과 관련된 상당한 양의 테스트 후에 우리가 마침내 정착 한 아키텍처. 귀하의 경우, 이것은 마스터 역할을하는 20 명의 클라이언트 중 하나를 갖추고 있으며 TCP를 통해 서버에 연결하도록합니다.

그런 다음 서버는 해당 한 컴퓨터로 시리즈의 전체 명령을 보냅니다.

그런 다음이 기계는 UDP를 사용하여 다른 기계 (LAN의 다른 19 명의 다른 클라이언트)에 실시간 지침을 방송하여 디스플레이를 최신 상태로 유지했습니다. 우리는 여기서 몇 가지 이유로 UDP를 사용했습니다. 오버 헤드가 낮아서 총 리소스 사용을 줄였습니다. 또한, 실시간으로 업데이트하고 있기 때문에, 하나 또는 두 개의 "프레임"이 동기화되지 않았다면, 적어도 우리의 목적으로 충분히 눈에 띄지 않았다 (인간이 시스템과 상호 작용하는 사람).

그러나이 작업의 핵심 요점은 원활하게 작동하는 핵심 요점은 기본 서버와 "마스터"머신간에 지능적인 통신 수단을 갖는 것입니다. 대역폭을 가능한 한 낮게 유지하려고합니다. 당신과 같은 경우, 나는 아마도 20 대의 기계에 대한 현재 명령을 가장 작은 형태로 한 단일 바이너리 블로브를 생각해 냈을 것입니다. (필요한 경우 20 바이트 또는 40 바이트와 같은 것일 수 있습니다). 그런 다음 "마스터"기계는 이것을 다른 19 개의 기계와 그 자체로 번역하는 것에 대해 걱정할 것입니다.

이에 대한 좋은 점이 있습니다. 서버는 클러스터의 모든 시스템 대신 클러스터의 한 머신으로 전송하는 데 훨씬 쉽습니다. 예를 들어, 어느 곳에서나 말도 안되는 하드웨어 요구 사항이 없으면 하나의 중앙 집중식 서버 "드라이브"다중 클러스터를 효율적으로 가질 수 있습니다. 또한 클라이언트 코드를 매우 간단하게 유지합니다. UDP 데이터 그램을 듣고 말하는 모든 것을 수행하면됩니다. 귀하의 경우에는 20 개의 명령 중 하나가있을 것 같습니다. 따라서 클라이언트는 매우 간단 해집니다.

"마스터"서버가 가장 까다 롭습니다. 구현에서 우리는 실제로 다른 19 개 (별도의 프로세스)와 동일한 클라이언트 코드와 블로브를 가져간 "번역"프로세스와 동일한 클라이언트 코드를 가졌습니다. 글을 쓰는 것은 상당히 간단했고 잘 작동했습니다.