[딥 네트워크 - 미디어 데이터 송수신 프로토타입 구현 가능] RabbitMQ Service의 Exchange는 메시지를 받아서 Binding 규칙에 따라 연결된 Queue로 전달해서 대규모 미디어 데이터 송수신 구현 가능 ...

그동안 2 년 가까이 BLDC/PMSM 모터제어로 전류를 정밀하게 제어하는 방법을 찾으려고 관련 논문을 수백편 뒤져서 최근에 모터의 정밀 전류제어 구현 기법을 99 % 터득에 성공했다 ...

저는 그동안 모터제어만 판것은 아니고 카메라 이미지센서의 화질 보정 알고리즘을 터득하려고 논문과 특허를 수도 없이 뒤져서 결국 터득에 성공했다 ...

밥벌이를 하려고 이것만 한것은 아니다 ...

딥러닝 NeRF 논문과 StyleGAN 논문의 핵심 딥러닝 모델 설계 구조를 파악하느라 고생 좀 했다 ...

또한 구글 Transformer Model 기반으로 음성인식 구현을 위한 딥러닝 모델 세부 설계구조 분석도 결코 쉽지 않았다 ...

이것으로 밥벌이를 하려 99% 준비해 놨는데 경기가 죽어서 일꺼리 얻기가 하늘에 별따기라 너무 힘들다 ...

이렇게 힘들어도 나는 자신있다 왜냐하면 위에서 언급한 99 점 짜리 기술이 몇가지가 있으니 언젠가 반드시 기회가 오리라 나는 확신하기 때문이다 ...

제가 운영하는 딥 네트워크는  다음과 같은 프로토타입 구현 기술들을 보유하고 있습니다.

RabbitMQ Service는 AMQP 프로토콜을 구현한 메시지 브로커 시스템입니다. RabbitMQ Service의 Exchange는 메시지를 받아서 Binding 규칙에 따라 연결된 Queue로 전달하는 역할을 합니다.

RabbitMQ Service 의 Exchange는 다음과 같은 메시지 전달 방식을 가질 수 있습니다.
Direct Exchange: 메시지에 포함된 routing key를 기반으로 Queue에 메시지를 전달합니다. routing key가 일치하는 Queue로만 전달됩니다.
Fanout Exchange: routing key 관계없이 연결된 모든 Queue에 동일한 메시지를 전달합니다. publish/subscribe 패턴에 적합합니다.
Topic Exchange: routing key 전체가 일치 하거나 일부 패턴과 일치하는 모든 Queue로 메시지가 전달됩니다. 와일드 카드(*)와 해시(#)를 이용해 routing key를 표현할 수 있습니다.
Headers Exchange: 메시지 헤더를 통해 binding key만을 사용하는 것보다 더 다양한 속성을 사용할 수 있습니다. Header exchange를 사용하면 binding key는 무시되고, 헤더 값이 바인딩 시 지정된 값과 같은 경우에만 일치하는 것으로 간주합니다.

RabbitMQ Service 의 Exchange와 Queue를 바인딩하는 설계 방법은 다음과 같습니다.
Exchange와 Queue를 생성합니다. Queue는 반드시 미리 정의해야 사용할 수 있습니다.
Binding을 추가합니다. Binding은 Exchange와 Queue를 Link하는 것입니다. Binding 시에 목적지 Queue 이름만으로도 추가할 수 있고, 일부 Exchange type에 따라 routing key를 지정해서 메시지를 필터링 한 후 지정한 Queue로 보내도록 정의할 수 있습니다.
Producer가 메시지를 특정 Exchange & Queue에 전달하면, RabbitMQ는 해당 메시지를 적절한 Consumer가 소비(Consume)할 수 있도록 해당 메시지를 전달하는 역할을 수행합니다.

RabbitMQ Service 의 Queue에서 메시지를 받는 방법은 다음과 같습니다.
Consumer 어플리케이션은 Queue를 통해 메시지를 가져갑니다. Consumer 어플리케이션에서 Broker로 많은 연결을 맺는 것은 바람직하지 않으므로, 하나의 연결을 공유하는 Channels을 사용합니다.
Consumer 어플리케이션은 Channel을 통해 Queue에 접근하고, subscribe 또는 pull 방식으로 메시지를 받아갑니다. subscribe 방식은 Queue에서 새로운 메시지가 도착하면 자동으로 Consumer에게 알려주는 방식이고, pull 방식은 Consumer가 직접 Queue에서 메시지를 가져오는 방식입니다.
Consumer 어플리케이션은 받은 메시지를 처리하고, Broker에게 수신 확인(acknowledgement)을 보냅니다. 이때 Broker는 Queue에서 해당 메시지를 삭제합니다. 수신 확인 모델은 명시적으로 Broker에게 통지하는 방식과 Broker가 메시지를 전달하면 자동으로 삭제하는 방식이 있습니다.

클라우드 서비스 RabbitMQ를 사용한 메시지 큐 통신 방식으로 Publish/Subscribe 구현 기술 :  이 기술은 클라우드 서비스인 RabbitMQ를 이용하여 메시지를 발행하고 구독하는 방식으로 통신하는 기술입니다. 이를 통해 다수의 클라이언트와 서버 간에 실시간으로 데이터를 교환할 수 있습니다. 이 기술의 장점은 메시지의 안정성과 확장성을 보장하고, 네트워크 부하를 분산시킬 수 있다는 것입니다. 이 기술은 대규모 방송 서비스에서 다양한 콘텐츠를 전달하고 수신하는 데 적합합니다.

네트웍 장비 L3 / L4 장비의 네트웍 라우팅 정보 제어 기술 :   이 기술은 네트워크 장비인 L3 스위치와 L4 로드밸런서의 라우팅 정보를 제어하는 기술입니다. 이를 통해 네트워크 트래픽을 효율적으로 분배하고, 장애 복구와 보안을 강화할 수 있습니다. 이 기술의 장점은 네트워크 성능과 안정성을 향상시키고, 다양한 프로토콜과 애플리케이션을 지원한다는 것입니다. 이 기술은 대규모 방송 서비스에서 고속의 데이터 전송과 접속자 관리에 필요합니다.

대규모 방송 서비스 구현을 위한 프로토타입 설계 기술  :   이 기술은 위에서 언급한 두 가지 기술을 결합하여 대규모 방송 서비스를 구현하기 위한 프로토타입을 설계하는 기술입니다. 이를 통해 실제 서비스 환경에서의 성능과 안정성을 검증하고, 개선점을 도출할 수 있습니다. 이 기술의 장점은 실제 서비스에 적용하기 전에 문제점을 발견하고 해결할 수 있고, 최적의 서비스 구조와 아키텍처를 설계할 수 있다는 것입니다. 이 기술은 대규모 방송 서비스의 개발과 운영에 필수적입니다.

저는 이러한 기술들을 바탕으로 대규모 방송 서비스의 프로토타입을 구현하고, 사업화 개발 및 자문을 진행하고 있습니다. 저의 사이트에서 저의 포트폴리오와 경력을 확인하실 수 있습니다. 저와 함께라면 더욱 효율적이고 창의적인 대규모 방송 서비스를 만들 수 있습니다.

제가 운영하는  일인기업  딥 네트워크  기술총괄  장석원

기업블로그  :    https://videocodec.tistory.com/     

제 기업블로그 사이트도 자세히 살펴봐 주시구요 ....

이메일   :   sayhi7@daum.net

HP : 010-3350 6509