소켓통신에 더블버퍼링

이거는 주의하여야 하는 여지가 커요. 커널에서 SO_SNDBUF SO_RCVBUF 가지고 있어서 사실 어플이 패킷을 이르게 처리하지 않았다 하더라도 데이터를 계속 받아요. 스레드를 2개 사용하던 잡 태스크를 2개 사용하던 한번에 패킷 2개를 처리하겠다 이럼 더블 버퍼링은 효과기 있을거여요. 이렇게 하면 커널에서 데이터를 두 개 끄집어내서 2배에 속도로 처리가 되게쩌.

이렇다 하더라도 tcp 소켓 통신은 스트리밍을 이해하여야 하고 nagle 로직이 들어가면 nodelay 커스텀 flush 하지 않는한은 패킷이 합치거나 잘려져서 전달되어져요. 이거는 병렬처리에 앵간이 제약이 걸리는거여서 잘 처신 하여야 해요.

GET /

 HTTP/1.1

위에 처럼 극단적으로 패킷이 나누어졌다 이럼 경계를 모르게 되어서 버려야 하거나 재조립 하거나 하여야 하게쩌. (아님 항상 1024 고정 길이 패킷만큼 읽는 거로 약속하거나)

매번 고정된 크기에 패킷을 가져오는 거이면 더블버퍼링, 트리플버퍼링 .. 이케 하던 1024 바이트씩 가져오는 거여서 위에처럼 잘리는 현상이 안생기는 거여요. 대신 http 표준 규격 같은 거는 버려야 하면서도 오버헤드가 커요.

사실 상대방에 좌표 수신 같은 거는 일부 패킷을 버려도 되는 거여서 udp 소켓을 사용하는 방법으로 하여도 좋게쩌.

서버에서 더블버퍼링을 앵간이 하지 않는 이유는 위에 이유가 있으므로 신중하여야 해요.