오류 원인을 찾기가 어렵네요.

자문자답합니다.더미 클라이언트에서 2인 이상의 세션을 넣었을 때만 해당 증상이 일어나는 걸 보고 고민고민하다가 발견했습니다. 아무리 봐도 코드는 문제 없었거든요.이전 코드에서는 브로드캐스팅을 하지 않고 각각의 세션에게만 에코를 해주니까 클라이언트가 수신할 때 서버가 송신해준 것만 딱딱 받았어요.여러 세션이 브로드캐스팅을 해주면, 서버가 여러 번 송신하는 데이터들이 세션에서 한 번에 받는 일들이 생기고 이게 누적되면서 눈덩이처럼 주고받는 데이터가 불어나더라고요.이상입니다.

Dfs 함수의 순방향 간선 예외 체크 로직에 대해 여쭤봅니다.

1년 지난 질문이지만 제가 답변해보겠습니다.순방향 간선의 존재는 그래프를 그려보면 어렵지 않게 찾을 수 있긴 해요. DFS 스패닝 트리가 만들어졌을 때 0 -> 1 -> 5 경로가 트리 간선일 경우, 0 -> 5가 존재하는 간선이 순방향 간선이에요. 즉 순방향 간선은 트리 간선에 포함되지 않는 간선입니다.순방향 간선은 조상에서 자손으로 가는 일종의 지름길 역할을 하기 때문에, 이미 방문한 노드 간에 발생합니다. 때문에 _discoveredOrder[there]가 != -1인 경우에 생겨요. _discoveredOrder[there]가 == -1인 경우는 트리 간선이에요.트리 간선(dfs 스패닝 트리), 순방향 간선, 역방향 간선, 교차 간선에 대해 다시 한 번 개념을 잡아보세요🙂

writeCount는 원자성 보장하지 않아도 되나요??

제가 이해한 바를 바탕으로 조금 더 풀어서 설명을 해보겠습니다.WriteLock()에서 expected = EMPTY_FLAG을 하고 나서 cas 연산을 하잖아요. 경합을 통해서 그 함수의 반환 값으로 true를 얻어낸 스레드'만' ++writeCount를 할 수 있습니다. 그러므로 writeCount에서 경합하는 일이 생기지 않습니다.write count를 잡고 있는 스레드는 중첩해서 락을 잡을 수 있는(락을 획득하기 위해 블락 당하지 않도록) 구조로 되어 있습니다. thread id를 확인해 write lock을 잡고 있는 스레드와 동일한 스레드라면 ++writeCount 연산을 합니다. 같은 스레드에서 진행하므로 경합이 발생하지 않습니다.이 두 경우 모두 writeCount에서 경합이 일어나지 않습니다!

WaitForSingleObject의 Auto reset 처리는 원자적인가요

커널에서 이뤄지는 거라서 thread-safe 합니다.

파일 송수신 테스트

패킷 보면 헤더 이후에 처음으로 c8 00 00 00이 존재하는데, 이 값은 10진수로 200입니다. 열거값 CMD_SND_FILELIST이 먼저 send되었기 때문이고요.그다음이 1c 03 00 00인데 이 값은 10진수로 796이죠. cmd.nSize에 해당하는 부분인데 sizeof(g_flist)는 4이고 sizeof(g_aFInfo)는 FILEINFO 구조체가 3개 존재하는 배열입니다. FILEINFO 구조체의 크기가 264bytes입니다. 264 * 3 + 4을 하면 796이 나옵니다.