햇갈리면 망하나요
이번 달만 하더라도 10가지를 넘어요.
물론 하려고 하는 사람이 감당 가능하면 말려야 하는 이유가 없겠쩌.
컴퓨터 프로토콜에는 앵간한 기법을 사용할 수 있는데 복잡해질 수록 사람에게 불리한거 아나요. 이런 이유로 quic 프로토콜에 스트리밍은 전통적인 tcp 시퀀스를 따라요. tcp는 1970년대에 개발되었쩌.
지난해 3달 동안 사이드로 quic 프로토콜을 보았는데 결과적으로 너무 무겁다는 거여요.
문서 RFC 9000 - QUIC: A UDP-Based Multiplexed and Secure Transport
업스테이지에 애스크업이 quic 프로토콜이 슬라이딩 윈도우를 사용한다고 안내하는거 킹받지 않나요. tcp 프로토콜은 패킷 시퀀스가 약속이어서 전송 속도를 늘릴려면 한번에 더 많은 데이터를 보내야 하고 이럼 MTU 1350-1500 사이에 프레임이 여러 장으로 단편화가 생겨요.
참조 Unlocking QUIC’s proxying potential with MASQUE
quic 문서 14. Datagram Size 절을 보면 대충 단편화는 없어야 한다고 선을 그었쩌.
솔까 단편화 2개 정도는 감안해야 무게를 덜어넬 수 있어요. 물론 커널에서 이케이케 처리를 하겠지만 어플에서 처리할 데이터가 줄고 런타임이 스크립트 언어이면 이론적으로 보면 앵간한 효과가 있어요. 실제 관측을 하여야 하겠지만 quic보다 가벼우면 된 거 아니나요. 어플리케이션에서 PMTU를 1350, 2700 이정도 정하고 선택적으로 단편화를 걸면 되는거여요.
찾아낸 오류. 하찮은 ai를 사용하면 햇갈려서 망해요.
acknowledge를 계산하려면 상대가 수신한 상태 값을 잘 받아야 하는데 설계를 틀어서 패킷 2번째 마다 상태가 변한다고 하였다가 전송 아이디를 가지고 상태를 측정하고 있었쩌 .. 이럼
Ａ：ＩＤ｜ＡＣＫ｜ ｜ＡＣＫ｜ＩＤ：Ｂ
０｜ ０｜００－＞｜０ ｜
｜ ０｜＜－００｜０ ｜０
｜ １｜＜－００｜０ ｜１
１｜ １｜００－＞｜１ ｜
２｜ １｜０１－＞｜１ ｜
｜ ２｜＜－０１｜１ ｜２
｜ ２｜＜－０１｜１ ｜３
３｜ ２｜０２－＞｜１ ｜
．．
Ｎ｜ ２｜０２－＞｜１ ｜
위에 B만 전송을 하고 있다면 A로부터 상태를 받을 수 없고 이럼 빈 데이터를 보내서 상태를 알려야 하는데 B의 패킷아이디 id % 2 == 0 쳐서 상태가 변하는 조건으로 짝수 아이디만 보면 되어요.
ai도 못 잡아내는 하찮은 실수는 B를 사용하지 않았고 A의 패킷 아이디를 쳐서 id(3) % 2 == 0 이케되고 false이고 이럼 영구적으로 상태 패킷을 전송하지 않으므로 데드락나요.
설계를 좀 엎었다고 이런 하찮고 이상한 실수가 나가지고 2주를 태웠는데 3월에 반이나 지나서 앵간한거 아니나요.
rdp 연결이 되면 tcp에 타임스탬프만 계속 주는 듯 하고 이럼 연결이 끊어지면 소켓 타임 아웃을 걸어서 프로그램을 나갈 수 있어요. 흔한 방식인데 ..
