쪽팔리면 질문하지 맙시다. 소중한 답변 댓글을 삭제하는건 부끄러운 일 입니다
윗선에서 Zoom은 이러는데 우리는 뭐냐? 라는 성질내는 분이 계셔서 고민해봤는데
어떻게 가능한지 감도 안잡힙니다.
홈페이지를 보면
https://explore.zoom.us/ko/zoom-vs-gotomeeting/
...지원한다고 했지 안끊긴다는 소리는 없는 것 같은데...
아니 그것보다 45%나 손실되는 상태에서 정상적으로 통신이 된다는건가??
그냥 세션을 안끊고 버티는것 같은데??
라는 의문은 남습니다만, 혹시 관련 정보를 아는 분 계시면 부디 가르침을 주십시오 ㅠ_ㅠ
당연 원 화상과는 쪼끔은 다르겠죠.
과연 제대로 된 음성일지도 신경쓰이네요... 음
심해지면 그냥 끊김니다 45% 손실은 어떤의미 인지 모르겠네요
저 45%가 무슨 의미인지를 모르겠어요 ㅋㅋㅋ
음성은 왜곡된 내용으로 전달 할 수도 있겠네요
어떻게 오류 정정을 하는지 상상도 안가서 여쭤봅니다. ㅎㅎ;
아무리 보정해봤자 45%나 날아가면 원본이랑 완전히 다를테니까요
거기다 대역폭이 충분하면 재전송 (화면이나 음성이 순간 이상해지겠지만)해서 때우기도 하겠죠
재전송한다고 해도 재전송 데이터에서도 45% 손실이 발생할 수 있을테고
결국 얼기설기 이어붙여도 손실률이 20%는 나올것 같은데 말이죠
손실을 감수하도록 리던던시를 포함해서 두 번 전송(?) 하던가
손실 복원 기능이 쩔어줘서 반쯤 날아가도 나머지 데이터로 복원하던가
혹은 데이터가 겁나 많이 소모하도록(즉, 고품질로 전송해서 데이터가 많으면, 데이터당 단위 시간은 짧으니) 반쯤 잘려도 사람이 듣는데 지장이 없던가..
jitter buffer에 담아뒀다가 재생하면 되긴할...까요? 으허허헛;;
근데 운전하실땐 20으로 고정시켜드려요
5~10%만 손실이 발생해도 음성이 끊겨서 전화 못하겠다는 클레임이 들어오는데 말이죠
아무리 생각해도 45% 패킷손실에서 제대로 통화가 가능할리가 없는데 말이죠
OS에서 캐시를 늘려봤자 한계가 있을거고, 캐시를 미친듯이 늘려서 재전송을 한다고 해도
받는 쪽에서 패킷손실로 제대로 못 받으면 아무리 다시 보내봤자 한계가 있고
그 한계를 극복하기 위해 재전송을 반복하면 이미 실시간통화가 아니게 되니까요
이미 90년대에 완성된 기술일 겁니다
RDS와 비슷한 Protocol들이 있습니다.
Reliable Datagram Service인텐데 UDP처럼 Datagram 방식이지만 TCP처럼 Reliable 한 프로토콜 입니다.
결론은 방법은 많습니다
RDS라는건 결국 UDP 위에 TCP와 유사한 기능을 하는 레이어를 하나 추가해서 connection-oriented는 아니지만 TCP와 유사한 기능을 추가한거지 그게 일반적인 줌 회의 같은데서 패킷 드랍 45% 일어날 때 지연 없이 회의를 정상적으로 할 수 있게 뭘 해줄수 있는건 아니죠.
Packet Drop도 에러의 한 종류이지 다른 카타고리가 아닙니다
Error correction을 하다가 실패하면 push건 pull이건 resend를 해서 복원을 합니다.
데이터 관점에서의 보정은 복구와 차이가 있습니다.
복구는 Resend없이 다양한 데이터로부터 오류난 정보를 100% 복구하는 것이고
보정은 오류 난 데이터 복구가 실패 했을때 주변의 정보로 데이터를 만들어 내는 것을 포함합니다.
어차피 source-dest의 데이터가 100% 정합성을 요구하지 않는 ZOOM등의 프로그램에선 쉽게 복원이 가능합니다.
그런데 보정은 100% 정확도를 보장하지는 않습니다.
그것보다 Zoom에서 말하는 것은 45%는 패킷 drop이 있어도 서비스가 가능하다 수준으로 써있습니다.
어디에도 잃어버린 45%를 복원한 정보를 다른 회의 참석자들에게 제공한다고 나와있지 않습니다.
저 수치를 어떻게 얻었는지 몰라도 다른분들 말씀대로 랩 환경에서 설정은 최고 품질(예를 들어 10Mbps정도)로 해 놓고 패킷 45%정도 드랍되면 자동으로 품질 팍 낮춰 최저(128Kbps 정도)로 바꾸고 동일 패킷 여려번 재전송하면 가능할수는 있겠지만요.
Zoom이 작은 회사도 아닌데 홈페이지에 저렇게 당당하게 걸어두니까 어? 진짠가?? 싶기도 하고
혼란스럽니다. @_@