以最低的延迟从Linux中的多播套接字接收数据

Question

In HFT trading application I need to receive data from udp multicast socket. The only requirement is latency - this is so important that I can "spent" one CPU core. It's ok to spin or whatever. This is what I currently have in Windows:

void Receiver::ThreadMethod() {
    //UINT32 seq;
    sockaddr_in Sender;
    int SenderAddrSize = sizeof(Sender);

    while (stayConnected) {
        int res=recvfrom(socketId,buf,sizeof(char) * RECEIVE_BUFFER_SIZE,0, (SOCKADDR *)& Sender, &SenderAddrSize);
        if (res == SOCKET_ERROR) {
            printf("recvfrom failed, WSAGetLastError: %d\n", WSAGetLastError());
            continue;
        }
        //seq = *(UINT32*)buf;
        //printf("%12s:seq=%6d:len=%4d\n", inet_ntoa(Sender.sin_addr), seq, res);
        unsigned char* buf2 = reinterpret_cast<unsigned char*>(buf);
        feed->ProcessMessage(res, buf2);
    }
}

recvfrom blocks, so it will be likely very slow (or i'm wrong?). I should rewrite this for Linux and achieve the best latency. I need to process just ONE socket per thread, so I assume I should NOT use epoll as it designed more to process many sockets. What should I use?

upd i've found similar question Low-latency read of UDP port

Answer 1

In UNIX, you should use fcntl to set your socket non blocking :

fcntl(socket, F_SETFL, O_NONBLOCK);

Additionally, if you client needs to process multiple sockets (eg to aggregate multiple feeds), you should use a select call to process multiple file descriptors at once, and see which socket has available data, if any (this will, among other things, avoid to loop through all the sockets for nothing)

As for the latency, other factors such as the NIC type and configuration, the kernel settings (possibly having a NIC that bypass the kernel) will have considerable impacts on the latency (to be measured).