How do I turn off the Nagel algorithm in LabWindows?

[Gwengineer]

I too am having TCP/IP problems with packet sizes.

I'm reading from a file then calling ClientTCPWrite() to write the data I just read from the file to my server, reading from a file, calling ClientTCPWrite(), and so on, and so on.

Instead of my server receiving a packet everytime I do a ClientTCPWrite() something (LabWindows?) is bunching a bunch of them together and sending big packets (4380 bytes of data). My ClientTCPWrite() data size is usually less than 100 bytes.

Even if I call ClientTCPWrite() with a data size of around 4K (like 4032) my server is still receiving packets that are bigger than the ClientTCPWrite() data size.

If I call ClientTCPWrite() with a data size of around 8K my server is still receiving packets around the 4380 byte size.

It seems as though this could be caused by the Nagle algorithm?

I tried to use the responses here to turn off the Nagle algorithm.

I got the GetHostTCPSocketHandle) call to work but when I tried to use setsockopt() I get undeclared identifiers for IPROTO_TCP and TCP_NODELAY and a missing prototype for setsockopt(). I can find the prototype for setsockopt() and the define for TCP_NODELAY in winsock.h but when I try to include it I get all sorts of redeclaration and redefinition errors. I can't find the define for IPROTO_TCP anywhere.

I'm using LabWindows/CVI version 7.1.0 (306) (WinNT/2000/XP) on a PC with Windows XP Professional, version 5.1, service pack 3.

Can you help me gain more control over my TCP/IP packet size?

Thank you!

Gwen

P.S. I tried to post this on an existing thread that was similar and reopening that thread but it kept closing. I hope I'm not doubling up on anyone.

[jr_2005]

Why are you worried about the TCP/IP packet sizes? TCP is a high level protocol which offers a significant degree of abstraction from the underlying network mechanisms and gives you a reliable connection between two end points, along which you transfer data in whatever format you like. Unless you're writing your own TCP implementation, you shouldn't need to be concerned with the nuts and bolts of the low level workings.

What is your server that CVI is attempting to connect to? 

JR

[Gwengineer]

Thanks for the response JR.

We're not so much worried about packet size as we're wanting our data to get transmitted as quickly as possible even if it means more and smaller packets.

We are sending command strings and we were wanting our command strings to arrive intact so that our server wouldn't have to spend as much processing time parsing. We may have overcome that issue on the server size but I'm not putting any money on it yet.

The server is a netburner board with a RTOS running our own proprietary s/w.

Is there a way to turn off the Nagel algorithm?

Thanks again! Gwen

[jr_2005]

I've never delved into the Nagel stuff so I can't be of any help there, sorry.

Does not your custom TCP stack deliver exactly the same packet as you submitted to the CVI libraries for transmission?? A fundamental requirement for a TCP implementation, I would have thought!

JR

[Gwengineer]

If anybody else can help me with turning off the Nagel algorithm I'd appreciate it.

Our proprietary s/w running on the netburner board does receive all of the data we send to it. However if I call ClientTCPWrite() with a 43 byte packet, then call it again with an 87 byte packet and then again with a 54 byte packet my server might receive a a single packet with 184 bytes. Or it might receive two packets, one with 43 and one with 141.

So while the low level TCP hangs onto my 43 byte packet waiting for more packets to send all at one time my server loses time it could be spending processing my 43 byte packet.

The part that I really don't like is if I send multiple packets in the 4000 byte range my server tends to get uniform packet sizes but bigger than 4000 bytes. So the first packet gets some bytes from the second packet tacked onto the end of it before it's sent out. Then what's left of the second packet gets some bytes from the third packet tacked onto it's end. And so on. And so on.

I understand the purpose of the algorithm. Just for my requriements I'd like to be able to turn it off.

[Snowman 6008]

Where were you getting the information you previously mentioned on how to turn off the algorithm, that function appears to be a windows SDK function http://digital.ni.com/public.nsf/allkb/A6ABC151D525C38586256B8400559CC5 and we do have some documents about calling windows SDK functions from CVI

http://digital.ni.com/public.nsf/allkb/4D03093F2079ABDD86256969006E9ECC?OpenDocument . If speed is your primary concern have you considered UDP communication? 

[Gwengineer]

Hi Richard,

Before I posted I looked around at other posts to see if I could find the answer. I ran across a post with the subject "A way to disable NAGLE of windows SOCKET" posted by Naemeh with responses from dummy decoy.

Other people on my design team did not want to use UDP because there is no guarantee that you won't lose data?

I'll take a look at the links you provided.

Thank you, Gwen

[OVR_CZ]

Hi,

    you need to include "Winsock.h" and add WSOCK32.lib to your project

    Winsock.h can be found in C:\Program Files\National Instruments\CVI71\sdk\include

      {or similar but not the same version of file on MSDN/or Google}

    WSOCK32.lib can be found in C:\Program Files\National Instruments\CVI71\sdk\lib

    or you can generate your onwn by labwindows

      (open header file(winsock.h or you own file),then selecet menu "Options"/"Generate DLL import library")

    or  you can genereate source code for import function from library by "Options"/"Generate DLL import library source"

      see to attached file for example

[wally_666]

---

Other people on my design team did not want to use UDP because there is no guarantee that you won't lose data?

---

This is true, but if client and server are always on the same subnet, as often the case with embeded PC applications, the error rate is essentially zero and you deal with it about the same as you would witn RS232.

--wally.

[cymrieg]

Why don't you use VISA instead of using winsock directly? If you use a socket resource in VISA you get a TCP connection and by default the nagle algorithm is off. But if you so wish you can control the nagle through the VISA attribute: VI_ATTR_TCPIP_NODELAY.