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
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).
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.