locked
Select method of TCP/IP control RRS feed

  • Question

  • Windows 7, Visual Studio 2008, 2012, C++, Windows sockets

    Summary: what is the best method for a low overhead and high data rate TCP/IP communication link?

    My application acquires telemetry data, chews it up a bit, and sends data to a client via TCP/IP.  The parameter rate is about 500K 32 bit values per stream and the overhead required by the client triples the volume to about 3 Mbytes per second.

    I currently use blocking sockets with attendant problems and have been trying to get to non-blocking.  After many searches I found this site http://www.winsocketdotnetworkprogramming.com/ which has some real good information.  Now I have found out about Winsock Kernel Functions (WSK), Callback Functions, and Transport Driver Interface (TDI). 

    I don’t know where I should concentrate my efforts.

    This application will have one output connection.  It takes the server role and expects no replies from the client.  Once the server / client link is established it only needs to know that the link remains in effect and there have been no errors.  In other words, once running, it is very simple, just send the data, and with the absolute minimum of overhead.

    I tried CAsyncSocket and it worked fine at relatively low data rates, but kept returning “would block” errors on the send.  I created a buffer array to hold the data until getting the OK to send, but the buffer kept filling up so I concluded that there is too much overhead in that wrapper class.

    The blocking mode works at the high data rate.  It works with four copies running as we get data from multiple sources during a mission.

    The options I see right now are:  First as described in the above noted site:  WSAAsyncSelect, WSAEventSelect, overlapped (I don’t need multiple ports) and completion port (again, don’t need multiple ports).  Now I have discovered the Winsock Kernel Functions (WSK) and the Transport Driver Interface (TDI).  I can find the Microsoft descriptions but they are not written for the programmer who does not already fully understand them.  Google searches on these topics have yet to help any.  I am willing to grind my way through them, but would prefer to hear from someone that understands the options before jumping in head first.

    Again, once the socket has been initialized and connected its use will be simple so I am thinking I want the lowest API level I can get and I will deal with whatever complexity that entails.

    My Question:  What path should I pursue?  Where should I look for guidance?


    ~jag77 We need to know what a dragon is before we study its anatomy. (Bryan Kelly, 2010)

    Sunday, November 17, 2013 3:52 AM