UDP는 완벽하게 실행 가능한 프로토콜입니다. 올바른 작업에 적합한 도구와 동일한 예입니다!
UDP 데이터 그램을 기다리는 프로그램이 있고 다른 프로그램을 기다리기 위해 반환하기 전에 처리하기 위해 프로그램을 종료 한 경우 경과 된 처리 시간은 항상 최악의 데이터 그램 도착 속도보다 빠를 필요가 있습니다. 그렇지 않으면 UDP 소켓 수신 대기열이 채우기 시작합니다.
이것은 짧은 버스트에 대해 허용 될 수 있습니다. 대기열은 수행 할 작업을 완료 할 때까지 데이터 그램 대기열을 만듭니다. 그러나 평균 도착률로 인해 정기적으로 대기열에 백 로그가 발생하면 프로그램을 다시 설계해야합니다. 여기에는 두 가지 주요 선택 사항이 있습니다 : 숙련 된 프로그래밍 기술을 통해 경과 된 처리 시간 줄이기 및/또는 프로그램을 멀티 스레드하십시오. 프로그램의 여러 인스턴스에서로드 균형 조정을 사용할 수도 있습니다.
앞서 언급 한 것처럼 Linux에서는 proc 파일 시스템을 검사하여 UDP가 무엇인지에 대한 상태를 얻을 수 있습니다. 나는 /proc/net/udp 노드를 cat 예를 들어, 나는 이런 식으로 뭔가 얻을 :
$ cat /proc/net/udp
sl local_address rem_address st tx_queue rx_queue tr tm->when retrnsmt uid timeout inode ref pointer drops
40: 00000000:0202 00000000:0000 07 00000000:00000000 00:00000000 00000000 0 0 3466 2 ffff88013abc8340 0
67: 00000000:231D 00000000:0000 07 00000000:0001E4C8 00:00000000 00000000 1006 0 16940862 2 ffff88013abc9040 2237
122: 00000000:30D4 00000000:0000 07 00000000:00000000 00:00000000 00000000 1006 0 912865 2 ffff88013abc8d00 0
이에서를, I는 사용자 ID 1006가 소유 한 소켓, 포트 0x231D (8989)를 수신하는 것을 볼 수 있고,받을 수 대기열은 약 128KB입니다. 128KB가 시스템의 최대 크기이기 때문에 도착하는 데이터 그램을 따라 잡을 때 내 프로그램이 약해진다는 것을 알 수 있습니다. 지금까지 2237 개의 드롭이 있었는데, 이는 UDP 레이어가 소켓 큐에 더 이상 데이터 그램을 넣을 수 없으며 드롭해야 함을 의미합니다.
시간이 지남에 따라 프로그램의 동작을 볼 수 있습니다. 사용 : netstat 명령이 같은 일에 대해 않는 것이
watch -d 'cat /proc/net/udp|grep 00000000:231D'
참고 : 내 위니 프로그램 netstat -c --udp -an
내 솔루션은 멀티 스레드 될 것입니다.
건배!
감사합니다 rx_queue, 나머지는 - 업데이트 참조) –
@ Julia 누가 사용할 프로토콜을 선택할 수 있다고 말합니까? 어쩌면 그는 기존 클라이언트를 지원하기 위해 UDP 기반 프로토콜을 구현하고있을 수도 있습니다. – steffen
Poster는 UDP 통계 모니터링에 대해 알고 싶어하며 어떤 프로토콜을 사용할 지에 대해서는 의견이 없습니다. 먼저 레이어에서 손실이 발생하는 곳을 확인함으로써 수정 작업을 수행 할 수 있습니다. – RickS