배경
- 지금 하는것들 전부 네트워크 기반.
- 앞으로도.
- 매번 조금씩 달라지는게 싫음 or 귀찮음
- ex) …
- lib로 좀 널널하게 만들고 가져다 썼으면 좋겠음
- 특히 A client-server-B client 구조가 많고 client 는 양 단에 각각 많음
- A군은 2자리, B군은 3~4자리
- 양단 1:1 통신이나 src, dst는 매번 달라지고 broadcast는 없음.
- message길이도 다 다름.
- 연결이 끊기면 안되고 recon, 이전 연결에 대한 정리에 민감해야함
- 네트워크 끊김, 연결 지연에 오만 그지같은 상황이 많음
- 실제 환경에서 조금 더 상황을 구리게 씀… 이래야 포괄적으로 쓰이겠지
이전에 시도했던것들
아래 항목들은 딱히 테스트는 안해봤거나 깊이있게 하지 않았을거임
- blocking socket
- 가장 간단, 보통 배울때 한번씩 해본거 그대로.
- C-S-C에서 C가 많아질수록 thread가 너무 많은데 이게 싫음 S입장에서 1C당 최소 1개식. -> 10, 20 개씩 양단에 연결된다면 30개 생성
- 근데 사실 thread가 한 app에 얼마나 많이 허용되는지 모름. 찾아봐도 딱히..
- 특히 thread가 form에서 쓰일때랑 console에서 쓰일때랑 다른게 console는 꺼지면 다 소멸되는데 form에서는 form이 꺼져도 thread는 살아있는경우가 있었음 이래서 가급적 적게 쓰고싶음.
- 애초에 이런 리소스 정리 안한 내잘못이긴함
- select
- 이건좀 가물가물함
- 아마 위에꺼를 벗어나고자 찾다가 얻어 걸림
- 배열같은거에 socket죽 늘어놓고 순회해 가면서 확인해서 받아오는식 이었던걸로 기억.
- 지금 기억엔 .. 1번 보는중인데 100번꺼가 들어오면 갈따까지 못봄 근데 우선순위가 더 높으면? ..
- 이론상 봤던게 그렇고 해결은 했던걸로 기억하는데 문제는 연결이 많아지고 구조가 복잡해지고 하면 안될것같음(진짜 잘 짜야될것같음)
- 그래서 포기.
- Begin-end(APM)
- 초창기에 block/nonblock, sync/async에 대해 알아볼일이 있었음 그러다 찾게됨(이거 정리 가능?)
- 이게 원하던 모델이었음
- 암튼 APM이 그 설명임.
- IAsyncResult BeginOperator -> EndOperator(IAsyncResult) 이런식이고 IAsyncResult은 정보를 갖고있음
BeginReceive가 예시. - 근데 내가 이거 이해를 못함 처음에 참고했던게 좀 복잡했는데 당연했던게 예시를 위한 코드가 아니었고 이미 쓰이고 있던 것의 일부를 보다보니 그랬음.
내 기억으로는 “여기서 시작해서 (쭉 내려가더니) 여기서 끝나고 또 이걸 넘기고 이건 무슨 정보를 갖고있고 이런이런 처리 하고 끝.” 딱 이렇게 들림. - select로 하던걸 못쓰게 되었고 이걸 빨리 쓸라는데 이해가 안됨 더 쉬은건 없나 찾게됨
- [server] // [client] 예제
- 그러다가 좋은 핑계거리를 찾음 Asynchronous programming patterns
- Async(TAP)
- 위 핑계거리에 따르면 begin-end 는 레거시임 지금생각해보면 이거굳이 신경 안쓰고 했어도 된것같긴한데 android 할때 deprecated된거 쓰다가 나중에 다 빨간불 들어와서 바꿨던적이있는데 그 경험을 다시 하기 싫었음 절대.
- BeginRead 여기도 첫줄에 보듯이…
- 무튼 요걸 기반으로다가 한다.
재료
- 알았으면 하는 것들
- 맛집
목표
배경에서의 문제점들이 없어야함.
구조적인건 나중에씀.
NCC는 가제
- lib로 만들고 외부에서 보이는 부분이 별로 없었으면함.
- 위 참고자료들에서 처리 흐름을 따르고 구조만 바꿨으면함..
위에 다 핵심은 비슷하긴함. - 쉽게.
- 각 개체는 연결이 일관적이지 않을 수 있음(?)
- conn/disconndp 에 대한 즉각반응, 상황에 따라 필요한 시간들이 다른데 이걸 어느정도 통일하고싶음
- RemoteEndPoint에 대한 상태 짐작(?)(ex.Ping, KeepAlive)
- 여기서 message에 대한 검증을 하고 app로 순수 message를 줬으면함 -> 요거 전용 프로토콜 만들자는소리
- 이건 원래 그러긴 할텐데 필요해보임..
- coap도 내 message에 coap입히고 udp입히고
여기도 user message에 ncc입히고 tcp입히고 - 단, user입장에서 send/recv message는 원래 send/recv했던 message그 자체만 볼수있게.
- client는 그 수가 상관없이 message를 동시에 보낼 수 있음….보냄.
- 계속 추가 예정
more
- 암호화
- 대용량
- 다른 프로토콜
Comments powered by Disqus.