팔아픈거도 번아웃이 맞으나 보아요

개발하는데 팔 아프면 하찮은 실력이지 않나요. 정말 이럼 접어야 하겠다.

udp 프로토콜 개발 하나 하자고 심플한 프로토콜을 정리하였는데, 결과적으로 어플을 만드는데 실제로 필요한 스펙은 stun 연결을 수행하여야 하고, symantic NAT 들은 ping 패킷을 보내면 pong 패킷을 받지 못하고 상대가 보내주는 패킷을 받아야 하는데 이럼 ping 패킷을 받아서 최종적으로 수신이 이루어진 소스 포트에 연결을 하여야 하면서 양쪽이 synamtic NAT이면 망한거여요. 하찮은 이거 구현은 쉬워서 특별하게 건드릴거 없는데 어플은 앵간하게 난리가 났어요.

음 .. 사실 새로운 채널 협상 방법이 필요하여서 앵간한 이유가 있었쩌.

이케 구조만 노트하여서 여려번을 바꿔썻어요. 0111_1111과 1111_1110에서 1111_1110으로 하는 방법이 >> 1 비트를 옮기는 것 만으로도 캐스팅이 끝나서 좋아요. 반대로 하면 & 0111_1111 앤드 계산을 하여야 하는데 비슷할 거지만 비트 싀프트 명령어 구성이 단순하여서 일반적으로 빠를거여요. 이런 하찮은 문제를 빼고 보더라도 상대가 상호작용 하는 메세지는 pong 플래그가 있어야 하고 안 그럼 무한 상호작용이 생겨서 여분에 필드에 ping-pong 플래그를 넣었쩌. 사실 이것도 하찮아서 오래 걸리지 않아요.

＿１２３４５６７＿１２３４５６７＿１２３４５６７＿１２３４５６７
００００００００ＡＡＡＡＢＢＢＢＣＣＣＣＤＤＤＤＥＥＥＥＦＦＦＦ
．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．

정말로 앵간한 거는 어플리케이션 구현에 있었는데 프로토콜 자체에 개발은 이만하면 쉬운 편에 속하지만 이거를 프레임워크나 라이브러리로 만드는 거는 적절한 상황에 잘 대응이 되어야 하여서 난리가 났쩌. 결과적으로 하나에 소켓이 여러개에 커낵션을 가지면서 각자에 채널을 가져서 망한거 였는데 .. udp 프로토콜은 구조가 단순하여서 tcp와 다르게 하나에 포트 필드만 사용하여서 브로드캐스트가 되는 것이고 이럼 커넥션 모델과과 채널 모델은 .. 채널도 데이터그램 스트림 이케 2개 채널이어서 이 정도면 혼돈에 카오스가 아니었겠나요. 게임 네트워크에 사용할 작정이지만 RDP 프로토콜에 연결이 우수하여 UDP 통신을 사용 중입니다 이거 메세지 보려고 ..

생각 한 대로 다 바꾸었는데 오류 0 경고 0 보는데 일주일이 걸린 것 같쩌. 3월 이라니 이럼 ㅠ.

예컨데 오픈소스 quic 프로토콜 라이브러리들은 먼저 stun 연결을 수행하거나 turn 연결을 할 수 없는 구조이어요. 머 ㅐ킹을 하여서 이케이케 구현하는 방법이 있겠지만 애초부터 연결할 상대가 1:N 이면 망한거여요. 이럼 quic p2p는 앵간하게 오래 걸리겠다는 전망이어요. 이거를 webrtc에 stcp 데이터 채널 대신에 quic을 사용하겠다고요.