For unrelated reasons, I can't directly receive the TCP stream. I must copy the TCP data from a running stream to another server. I can use tap or just port-mirroring on the switch. So I can't use any network stack or leverage any offloading.
I also need to modify the received data, and add few application headers before sending it as a multicast udp stream. Winsock is userland. What I want to do is in the kernel, even before ip_input. I guess it should be faster. I am looking at netFPGA too, but prefer to do this in software. Best regards, Dan On Thu, Nov 8, 2012 at 7:36 PM, Johan Beisser <j...@caustic.org> wrote: > On Thu, Nov 8, 2012 at 4:12 AM, Dan Shechter <dans...@gmail.com> wrote: >> Hi All, >> >> <current situation> >> A windows 2008 server is receiving TCP traffic from a stock exchange >> and sends it, almost as is, using UDP multicast to automated high >> frequancy traders. >> >> StockExchange --TCP---> windows2008 ---MCAST-UDP----> >> >> On average, the time it take to do the TCP to UDP translation, using >> winsock, is 240 micro seconds. It can even be as high as 60,000 micro >> seconds. >> </current situation> >> >> <my idea> >> 1. Use port mirroring to get the TCP data sent to a dedicated OpenBSD >> box with two NICs. One for the TCP, the other for the multicast UDP. > > You'll incur an extra penalty offloading to the kernel. Winsock is > already doing that, though. > >> 2. Put the TCP port in a promiscuous mode. > > Why? You can just set up the right bits to listen to on the network, > and pull raw frames to be processed. Or, just let the network stack > behave as it should. > >> 3. Write my TCP->UDP logic directly into ether_input.c > > Any reason to not use pf for this translation? > >> </my idea> >> >> Now for the questions: >> 1. Am I on the right track? or in other words how crazy is my idea? > > Pretty crazy. You may want to see if there's hardware accelerated or > on NIC TCP off-load options instead. > >> 2. What would be the latency? Can I achieve 50 microseconds between >> getting the interrupt and until sending the new packet through the >> NIC? > > See above. You'll end up having to do some tuning. > >> 3. Which NIC/CPU/Memory should I use? Money is not a problem. > > Custom order a few NICs, hire a developer to write a driver to offload > TCP/UDP on the NIC, and enable as little kernel interference as > possible. > > Money's not a problem, right?
