2017-12-21 1 views
2

현재 802.11 프레임에 대해 최상의 전송 성능을 얻으려고하고 있는데 libpcap을 사용하고 있지만 원시 소켓 (또는 다른 가능한 방법)을 사용하여 속도를 높일 수 있는지 궁금합니다. Raw Sockets 대 Libpcap의 성능 전송

이미 이전에 생성 된 디바이스의 libpcap 핸들이 간단한 예 코드를 고려

char ourPacket[60][50] = { {0x01, 0x02, ... , 0x50}, ... , {0x01, 0x02, ... , 0x50} }; 

for(; ;) 
    { 
     for(int i; i = 0; i < 60; ++i) 
     { 
      pcap_sendpacket(deviceHandle, ourPacket[i], 50); 
     } 
    } 

이 코드 세그먼트는 각각 별개의 CPU 코어를위한 스레드에서 수행된다. 어레이에 저장된 Radiotap 헤더가 포함 된 원시 802.11 프레임/패킷에 대해 이렇게하는 더 빠른 방법이 있습니까?

pcap_inject (동일한 기능이지만 다른 반환 값)에 대한 pcap의 소스 코드를 보면 패킷을 보내기 위해 원시 소켓을 사용하지 않는 것 같습니까? 실마리 없음.

다른 질문에 대한 답변이 많아서 성능 캡처에 신경 쓰지 않습니다. 레이어 2 패킷/프레임을 전송하기위한 원시 소켓이 있습니까?

+1

사용중인 OS를 지정하지 않았습니다. libpcap은 큰 차이를 만드는 크로스 플랫폼이기 때문에. 내가 가장 익숙한 리눅스를 가정하면, 이미 원시 소켓을 사용하고있다. 그러나, 당신은'PACKET_TX_RING'을 조사 할 수 있습니다. 나는 당신이 단일 시스템 호출 (그리고 AFAIK는 현재 libpcap에 의해 지원되지 않습니다 *)로 패킷의 전체 배열을 보낼 수 있다고 믿습니다.이 설정을하는 데 상당한 학습 곡선이 있습니다. –

+0

저는 리눅스를 사용하고 있습니다. 위의 예제에서 원시 소켓 구현을 수용하기 위해 몇 가지 변경을해야합니까? 나는 많이 추측합니까? 구조체와 같은 다른 프레임 레이아웃을 사용해야하거나 이미 배열에 저장된 프레임을 성공적으로 보낼 수 있습니까? 나는 libpcap이 그걸 처리 할 때 체크섬 만 빠져 있다고 믿는다. – RSS

+1

프레임 구조는 다르지 않습니다. 단지 바이트 배열입니다. 그러나,이를 생성하거나 tx_ring 메모리에 복사해야합니다. –

답변

1

길 해밀턴 (Gill Hamilton)이 언급했듯이 대답은 많은 부분에 달려 있습니다. 한 시스템에서 수퍼 게인을 확인한 경우 두 시스템이 모두 "실행중인 Linux"이더라도 다른 시스템에서 수퍼 게인을 볼 수 없습니다. 직접 코드를 테스트하는 것이 더 좋습니다.. 즉, 여기 내 팀이 발견 한 내용이 있습니다 :

참고 1 : 모든 이득은 프레임/패킷을 소켓에 쓰지 않고 분석하고 처리 한 코드에 대한 것입니다. 우리의 이익의 대부분 또는 대부분은 읽기/쓰기보다는 거기에있었습니다.

우리는 이더넷 프레임과 IP 패킷을 송수신하기 위해 직접 원시 소켓 구현을 작성하고 있습니다. MT7530 통합 이더넷 NIC/스위치가 장착 된 칩에서 MIPS 24K 5V 시스템 인 가장 가벼운 R & D 시스템에서 250 % -450 %의 성능 향상을 보았습니다. 은 지속 가능한 80Mbit을 처리 할 수 ​​있습니다. 인텔 셀러론 J1900 및 I211 기가비트 컨트롤러를 갖춘 매우 겸손하지만 훨씬 까다로운 테스트 시스템에서 libpcap 대 약 50 % -100 %로 떨어집니다. 사실 파이썬 dpkt/scapy 구현에 비해서 약 80 % -150 % 만 보았습니다. 은 일반적인 i5 Linux 듀얼 기가비트 시스템과 c libpcap 구현에서 약 20 %의 이득을 보았습니다. 따라서 엄격하지 않은 테스트를 기반으로 시스템에 따라 코드의 성능이 최대 20 배 차이가납니다.

참고 2 : 이러한 모든 이점은 사용자 정의 c 코드를 컴파일하는 동안 최대 최적화 및 가장 엄격한 컴파일 매개 변수를 사용할 때 발생하지만 c libpcap 코드 (일부 시스템에서는 모든 경고 오류가 발생하면 libpcap 코드가 컴파일되지 않고 누가 디버깅을 원합니까?), 그 차이가 덜 극적 일 수 있습니다. 5.0V와 1.5A를 넘지 않는 정교한 패킷 처리를 가능하게하기 위해서는 성능을 최대한 끌어 내야 할 필요가 있습니다. 따라서 궁극적으로 FPGA 일 수있는 맞춤형 ASIC을 사용할 것입니다. 즉, 버그없이 작업 할 수있는 많은 작업이 있으며 이더넷/IP/TCP/UPD 스택의 중요한 부분을 구현할 가능성이 높기 때문에 권장하지 않습니다.

마지막주의 사항 : MIPS 24K 시스템의 CPU 사용량은 사용자 지정 코드의 경우 약 1/10이지만, 그 대다수는 처리에서 얻은 것입니다.