월별 글 목록: 2014년 10월월

Front-End Development, Tip

해상도 단위 정보 Resolution

댓글 남기기

WebRTC API를 이용한 영상회의 프로젝트에 Peer to Peer가 연결된 상태에서 Resolution(해상도) 변경을 해야하는 이슈가 있어서 관련 내용을 정리해 보았습니다. (해상도 단위 정보 Resolution)

해상도 단위 정보 Resolution
해상도 단위 정보 Resolution

Below are most of the more modern display modes:

Mode Name Resolution
90p 160×90
180p 320×180
240p 352×240
360p 640×360
720p 1280×720
1080p 1920×1080

Below are the wide-screen and standard PC screen resolutions:

Mode Name Resolution
w288p 512×288
w448p 768×448
w576p 1024×576
VGA 640×480
SVGA 800×600
XGA 1024×768
SXGA 1280×1024

Below are the historical display modes:

Mode Name Resolution
CIF 352×288
QCIF 176×144
SQCIF 128×96
4CIF 704×576
16CIF 1408×1152
Front-End Development, Tip

OpenWebRTC

댓글 남기기
OpenWebRTC
OpenWebRTC

OpenWebRTC 는 에릭슨 연구소에서 만들어낸 WebRTC(Web Real Time Communication) 기반의
프레임워크인데요, 이 프레임워크를 WebRTC 분야의 활성화를 위해 2014년 10월에 오픈소스로 공개했습니다. (기사전문: 에릭슨, 구글·애플 제치고 웹RTC 표준 앞장)

이 오픈소스가 얼마나 완성도가 있고 쓸모있는지는 좀 더 지켜봐야 겠지만,
분명한것은 웹에서 영상통화를 하기 위해서 설치해야했던 플러그인들은 이제 필수가 아니게 되었습니다. 그 이유는 순수하게 브라우저에서 지원하는 API를 이용해서 구현이 가능해졌고, 사용자들은 다양한 디바이스에서 손쉽게 상대방과 얼굴을 마주 볼 수 있게 되었습니다.

저도  현재 관련 프로젝트를 진행중이지만,  WebRTC는 영상통화 이외에도 DataChannel API를 이용해서 P2P 통신이 가능하기 때문에 실시간 파일공유를 기본으로 활용 범위는 무궁무진합니다.
다음에 시간을 내서 기존에 정리했던 자료들도 한번 공유 해보려고 합니다.

오늘은 불금이니 이만 ㅋㅋ

[참고]

Front-End Development, IT용어정리

MQTT 이해하기

댓글 4개

PUSH서버 연동이 필요한 프로젝트를 진행중이라 관련 정보를 정리해 보았습니다.

MQTT(Message Queuing Telemetry Transport) 란 텔레메트리 장치, 모바일 기기에 최적화된 라이트 메시징 프로토콜 입니다.
더 다양한 앱과 서비스의 등장으로 HTTP등의 기존 프로토콜만으로는 커뮤니케이션의 다양한 요구사항을 수용 할 수 없게 되었고, 제한된 통신 환경을 고려하여 디자인된 MQTT 프로토콜은 모바일 영역의 진화에 따라 최적의 프로토콜로 주목 받고 있습니다.

MQTT (MQ Telemetry Transport) 이해하기
MQTT (MQ Telemetry Transport) 이해하기
[MQTT 프로토콜 설계의 의도]
  • 프로토콜이 차지하는 모든 면의 리소스 점유(footprint)를 최소화
  • 느리고 품질이 낮은 네트워크의 장애와 단절에 대비
  • 클라이언트 애플리케이션 동작에 자원 활용이 극히 제한적임을 고려
  • 다수의 클라이언트 연결에 접합한 Publish/Subscribe 네트워크 채용
  • 신뢰성 있는 메시징을 위한 QoS(Quality of Service) 옵션 제공.
  • 개방형 표준 메시징 프로토콜을 지향 –  제 3자(3rd Party) 기기 제조업체와 소프트웨어 개발업체의
    용이한 도입, 적용을 유도
[주요 특징]
  • IBM과 Eurotech(Arcom)에 의해 1999년 최초 개발
  • 센서/장치 + 모바일 기기들의 연결을 위한 프로토콜
  • MQTT 프로토콜 오픈소스로 공개 (http://www.mqtt.org)
  • 단순하고 미니멀한 Pub/Sub 메시징 체제
    • 기업 경계 박의 Edge 네트워크 장치와 기업 내의 백엔드 애플리케이션 간 메시지 교환에 접합
    • 간편한 메시징을 위한 직관적 verb set(connect/disconnect publish/subscribe) 제공
  • 오버헤드를 최소화
    • 가장 작은 메시지 사이즈는 2byte: 가변길이 MQTT헤더 + 애플리케이션 Payload
    • Payload 데이터에 중립적: 별도의 다른 애플리케이션 헤더 불필요
    • 클라이언트 라이브러리: C버전은 30KB, Java 버전은 100KB 내외
  • Pub/Sub에 있어서 메시징 신뢰성을 위한 세가지 QoS(Quality of Service) 레벨 제공

    • 반드시 전달되어야하는 중요 메시지에 대한 전달 보장
    • QoS 0 : 한 번만 전달하고 전송 여부는 확인하지 않음.
    • QoS 1 : 적어도 한 번 이상 전송하고 전송 여부 확인. (전송 여부 확인 패킷이 유실되면 중복 메시지 발생 가능)
    • QoS 2 : 메시지 전송 핸드셰이킹을 통해 정확히 한 번만 전달. (신뢰할 수 있지만 성능 저하 발생)
  • 클라이언트와 서버간의 연결을 잃었을때 이를 보정하기 위한 자체 기능
    Last will and testament: 클라이언트가 예고 없이 연결을 잃을 경우 이벤트가 서버에서 발생,
  • 서버 측에서 연결의 유실 여부 인지
    Durable subscription: 서버에 클라이언트의 구독(subscription)정보 저장됨,
  • 세션 종료 후 재접속 시에도 재작업 없이 Pub/Sub유지
    Clean session 기능: 연결 해제 후 다시 연결되었을 때의 이전 세션 유지/삭제 선택
[이외 특징]
  • FB 메신져가 이걸 사용. 국내 통신사 PUSH 서버도 이걸 사용함.
  • 일단 FB가 쓰니, 동남아권 Telco에서 패킷 걸리는 문제는 없을듯
  • Qos 0,1,2로 해서, 2 의 경우 message delivery를 gurantee함
  • 저전력!! 모바일 환경에 이게 중요함.
  • XMPP에 비해서 훨씬 경량. (XMPP는 XML, MQTT는 byte로 보내는데, 2바이트부터 시작)
  • MQTT 서버를 라즈베리와 같은 임베디드 서버에도 넣을 수 있음. IOT용!! 즉 Things가 서버가 될 수 있다!!
  • 대부분 사용자 인증만 제공 (user id/password 방식) 이것도 대부분 서버들이 파일에 저장한다.
    (IDM이나 KEY 시스템과 연계 필요)
  • TLS/SSL은 지원. X.509 인증서를 이용한 양방향 인증도 지원
[MQTT over WebSocket]

Websocket은 TCP socket과 많이 닮았지만, 차이점도 있다.
그 차이점은 브라우저에서 서버로 양방향 커뮤니케이션 연결을 시도 한다는 점이다.
웹소켓이 위치하면서 웹브라우저에서 웹 어플리케이션을 위한 first class MQTT 지원이 가능해졌습니다.
여기엔 몇가지 옵션이 있습니다.

  1. IBM의 MQ 7.5가 Websocket을 지원하게 되었다.
  2. Mosquitto broker는 예제를 포함한 Javascript client를 가진다.
  3. HiveMQ MQTT broker는 네이티브 웹소켓 지원을 한다.
[원문]
[참고]