일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- Pending Intent
- setContentIntent
- 안드로이드 알림채널
- notification manager
- notifications
- notification channel
- setPriority(NotificationCompat.PRIORITY_HIGH)
- 알림 인텐트
- NotificationCompat.Builder
- 안드로이드 알림
- 버전별 관리
- 알림 우선순위
- setDefaults(NotificationCompat.DEFAULT_ALL)
- android notification 예제
- 펜딩인텐트
- 안드로이드 알림 예제
- Today
- Total
공부용 블로그
protocol_4주차_Payload란 본문
1. Payload란?
데이터가 인터넷을 통해 전송되면, 전송 된 각 장치에는 헤더 정보와 전송되는 실제 데이터가 모두 포함됩니다. 헤더는 패킷의 소스와 목적지를 식별하는 반면 실제 데이터는 페이로드라고합니다. 헤더 정보 또는 오버 헤드 데이터는 전송 프로세스에서만 사용되기 때문에 목적지에 도달하면 패킷에서 제거됩니다. 따라서 페이로드는 대상 시스템에서 수신 한 유일한 데이터입니다.
-
When data is sent over the Internet, each unit transmitted includes both header information and the actual data being sent. The header identifies the source and destination of the packet, while the actual data is referred to as the payload. Because header information, or overhead data, is only used in the transmission process, it is stripped from the packet when it reaches its destination. Therefore, the payload is the only data received by the destination system.
(Payload Definition.pdf 문서 참고)
2. Actual data란?
패킷 또는 파일의 "실제 데이터"에서 전송을 위해 첨부 된 모든 헤더를 뺀 것과 모든 설명적인 메타 데이터를 뺀 것을 말합니다. 네트워크 패킷에서 헤더는 전송을 위해 페이로드에 추가 된 다음 대상에서 삭제됩니다. 키 길이 값 구조에서 키와 길이는 값 (페이로드)에 대한 설명 데이터입니다.
-----------------------------------------------------------------------------------------------------------------------
페이로드 유형이란 무엇입니까?
전송 프로토콜로서의 RTP는 전송하는 미디어 데이터의 유형과는 독립적입니다. RTP는 다양한 비디오 및 오디오 포맷을 전송할 수 있습니다. RTP로 전송할 수있는 일부 오디오 형식은 G.711, GSM 또는 PCM입니다. 전송 될 수있는 비디오 형식은 MPV, H261 또는 H264입니다. 훨씬 더 있습니다. RTP 패킷에 넣을 수있는 각 오디오 또는 비디오 형식을 페이로드라고합니다. 일반적으로 오디오 및 비디오 데이터는 압축 된 형식으로 전송됩니다. 그렇기 때문에 페이로드 유형이 오디오 또는 비디오 압축 형식이나 코덱을 정상적으로 나타내는 이유입니다. 각 형식에 대해 데이터를 RTP 패킷에 넣는 방법에 대해 서로 다른 규칙이 정의되어 있습니다. 우리는 여기서 아주 간단한 MJPEG 페이로드 RTP 패킷 화를 보여줍니다. MJPEG 이미지를 RTP 패킷에 넣기 위해 적용해야하는 규칙은 RFC 2435에 설명되어 있습니다. JPEG와 같은 단순한 형식조차도 여러 가지 특성이나 프로파일을 가지고 있습니다. JPEG만을위한 일반 RTP 패킷 화기의 구현은 이미 어려울 수 있습니다. 이것이 RTP 페이로드 패킷 타이 저가 일반적으로 압축 표준이나 속한 페이로드 RFC가 제공하는 자유도의 제한된 하위 집합을 고려하는 이유입니다.
-----------------------------------------------------------------------------------------------------------------------
RTP 패킷의 RTP 헤더의 길이는 12 바이트입니다. 상세한 구조는 RFC 3350에 정의되어 있습니다. RTP 헤더에는 다음에 대한 데이터가 들어 있습니다.
- RTP 프로토콜 버전
- 패킷 손실을 검출하기 위해 클라이언트에 의해 사용될 수있는 패킷 (시퀀스) 카운터
- 클라이언트에서 재생의 타이밍을 제어하는 타임 스탬프
- RTP 스트림의 유일한 식별자
RTP 헤더 뒤에는 RFC 2435에 설명 된 8 바이트 JPEG 특정 헤더가옵니다.이 이미지에는 이미지의 매개 변수를 설명하는 메타 데이터가 들어 있습니다.
- 너비와 높이
- 품질
- 컬러 포맷
- 프래그먼트 오프셋 (fragment offset) (이미지가 RTP 패키지의 용량만큼 커야하는 경우 스캔 데이터의 위치)
-----------------------------------------------------------------------------------------------------------------------
interleaving이란?(https://www.techopedia.com/definition/5683/interleaving)
정의 - 인터리빙 은 무엇을 의미합니까?
인터리빙은 불연속 방식으로 데이터를 배열하여 시스템을보다 효율적이고 신속하며 신뢰할 수있게 만드는 프로세스 또는 방법입니다. 시스템 레벨에서 인터리빙에는 다음과 같은 많은 용도가 있습니다.
- 저장소 : 하드 디스크 및 기타 저장 장치는 사용자 및 시스템 데이터를 저장하는 데 사용되므로 항상 적절한 방식으로 저장된 데이터를 정렬해야합니다.
- 오류 수정 : 데이터 통신 및 메모리의 오류를 인터리빙을 통해 해결할 수 있습니다.
- 다차원 데이터 구조
인터리빙은 섹터 인터리빙이라고도합니다.
Techopedia에서 인터리빙에 대해 설명합니다.
인터리빙은 메모리를 작은 덩어리로 나눕니다. 마더 보드 및 칩의 메모리 문제를 해결하기위한 고급 기술로 사용됩니다. 데이터가 메모리 덩어리에 액세스 할 수 있도록 대역폭을 늘리면 프로세서와 시스템의 전반적인 성능이 향상됩니다. 이것은 프로세서가 동일한 시간 내에 메모리에서 더 많은 데이터를 가져오고 보낼 수 있기 때문입니다.
인터리빙은 모든 종류의 마더 보드에서 지원되는 유일한 기술입니다. 이러한 기술을 구현하려면 고급 처리 관리 시스템이 끊임없이 필요합니다. 인터리빙은 대규모 조직의 서버에 효율적인 데이터베이스 및 통신을 촉진합니다.
인터리빙에는 다양한 유형이 있습니다.
- 양방향 인터리빙 : 두 메모리 블록은 읽기 및 쓰기 작업을 위해 같은 레벨에서 액세스됩니다. 겹치는 기회가 있습니다.
- 4 웨이 인터리빙 : 4 개의 메모리 블록이 동시에 액세스됩니다.
- 오류 정정 인터리빙 : 통신 시스템의 오류는 단일 공격보다는 높은 볼륨에서 발생합니다. 인터리빙은 이러한 알고리즘을 특정 알고리즘으로 제어합니다.
대기 시간은 인터리빙의 한 가지 단점입니다. 인터리빙은 시간이 걸리고 모든 종류의 오류 구조를 숨 깁니다. 이는 효율적이지 않습니다.
'설계 > Protocol' 카테고리의 다른 글
Protocol_6주차_OSI 7계층 (0) | 2018.07.10 |
---|---|
Protocol_5주차_WebRTC와 다른 프로토콜 비교 (0) | 2018.07.03 |
protocol_4주차_MPD와 m3u8파일은 왜 만들었을까? (0) | 2018.06.25 |
protocol_3주차_MPEG DASH (0) | 2018.06.12 |
protocol_3주차_TCP와 UDP (0) | 2018.06.11 |