My TCP/IP connection return randomly a "Not enough memory to complete this operation"

[Dave Korpi]

I refer to both threads. I do not think this error has anything to do with AI, DMA or any hardware. I think the OS is "getting confused" with the way LabVIEW is handling the tcp/ip protocol and it could be something to do with the configuration of the options in LabVIEW that will remedy it. After reviewing all the data I made these conclusions. Ready to have anyone show me the "real" answer and help to resolve this important issue. Please refer to this thread too: http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RNAME=ViewQuestion&HOID=506500000008000000AB3A0000&ECategory=LabVIEW.LabVIEW+General

Thanks,

Dave Korpi (Reference#401456) for talking to NI

korpi@starband.net

[kramer]

I had this problem with Labview 6i and finally figured it out ... Maybe this will help you : We are building a suite of software that runs as tcp client and report themselve "online" to a program that manage all the modules (programs) running, thus working as the server. I had the "not enough memory to complete this operation" with tcp/ip. the problem in our case occured both in windows nt/9X and 2000. The problem come from the Tcp/ip write function. We were writing the data string in two shots and reading it in two shots. At first, we were calculating the string lenght and doing a tcp/ip write of 4 bytes and then we were doing a tcp/ip write of the string (a flatten array in our case). What we changed to make it work was writing the whole string (the four bytes
and the flatten array) in one tcp/ip write operation.

also, Since we were doing the Tcp/ip reads in one thread, the tcp/ip write in another thread and managing the connexion in another thread, we had a problem of concurrence between the thread. Sometimes, when we were closing a connection in a thread and trying to read data on this same conncection, we had the 'not enough memory ... " error message. By implementing a system of flag (boolean) to assure that the line (connection) is free when doing an operation , we managed to solved all the "not enough memory ..." error problems ... hiope that this helps ..

Eric

[Stephane 696]

Salut Eric,

Your explanation match exactly with the way my handshake between my client/server works. I do not have a race when I close the connection but I send 2 packets, one for lenght and the other for data.

I will change my code for a kind of protocol with a single packet with the shape [CRCsize|size|CRCmessage|message] and read it with two calls (read [CRCsize|size] and read [CRCmessage|message]). That should solve my problem according with your explanation.

I will post some update later when my code will be updated and test.

Thanks,

Stephane

[Stephane 696]

Salut Eric,

I just double check my code. The problem you describe is not the same as the one I have. Just too bad. I use TCP server (one by connection). The protocol send a ack "GOOD" between the two packets. Something like this:

Sender Server (Receiver)

Send Size -> Wait for 8 bytes (CRC+Size)
Wait for 8 bytes <- Send the status
Send Message -> Wait for the Size bytes
Wait for 8 bytes <- Send the status

I cannot have a race like you have when you send the 2 packets in same time. I get a little more synchronization. My code also include error recovery not add in the exchange protocol describe. I have all my server in a sequential VI listen, exchange data and close connection.

I don't close any TCP connec
tion when the "Not enought memory to complete this operation" happen, all my servers are still up.

Looks like I will need to continue to look. But as in your case, the TCP look like making this problem. This is already a big step.

Thanks again for your reply,

Stephane

[Melissa G]

I came across something very interesting in one of the TCP/IP Example VI's that ship with LabVIEW. Take a look at the "Simple Data Server.vi". (This can be found in Help>>Search Examples>>TCP/IP>>Simple Data Server.) In the block diagram there is a delay with the note that says "Delay 25ms so we don't flood input queue on PC's running NT." Since we are seeing this issue on NT machines, there is obviously something "special" about NT and the way it handles the data sent and received.

What happens if you model your communication after this example? Try adding in a delay between when you listen and when you perform the write. Also, as a simple experiment, try running this "Simple Data Server.vi" along with the "Simple Data Client.vi". Try
it with and without the delay to see if the "Not enough memory" error appears.

[Dave Korpi]

Melissa and Stephane:

Thanks for the reply Melissa.

Stephane...

Does look like the error comes from Windows. Also looks like there is someone at NI who knows about special issues having to do with NT related to "flooding" This is why Melissa gave the example in the server. Therefore, the following conclusions to be validated by all:

1) I feel the problem comes from some specific "bug" in Windows NT that does not exist in Windows 9X. I think it is related to speed but need to have an exact answer to give customers.

2) The source of the problem is in the SERVER and not the CLIENT. I need this verified. If this is true it looks like we only have to determine a delay period to put in the exact right place in our server. I think it needs to be between the LISTEN and the WRITE. Some of the delay can be taken up by whast we are writing (for example an analog data acquisition might take 10 of the needed 25 milliseconds). The exact number of milliseconds is not known.

3) We need to understand, and get clear confirmation on the exact source of the problem (who is complaining) and what "routine" caused the complaint (the server in this case?)

My plan of action is to use the Simple Data Server and Simple Data Client that Melissa refered to and put a control in place of the 25 millisecont constant, build executables of these two and run them on an NT. I will then adjust the 25 millisecond control up and down to see if reducing it causes the "not enough memory..." error and if I increase it we have it go away...

If this comes to pass then we will know there is a relation to the delay and to the error.

Thanks,

Dave Korpi


THis means that I need to select the proper test code to send to Melissa.


Dave Korpi
22642 Indian Springs Road
Salinas, CA 93908
Phone: (831)-455-0418
Fax: (831)-455-0419
e-mail: korpi@starband.net

----- Original Message -----
From:
To: "Dave Korpi"
Sent: Wednesday, March 06, 2002 8:09 AM
Subject: Re: (Reference#401456) Phone Support E-Mail



Note: Your reference number is included in the Subject field of this
message. It is very important that you do not remove or modify this
reference number, or your message may be returned to you.


Hi Dave,

I've been following the different discussion threads to see if they can
provide any insight. The response by Eric was interesting, but doesn't
seem to be the cause of Stephane's problem...does it sound like yours? I
was thinking that it may have something to do with a connection being
closed, and then doing a read/write to that connection. This should
definitely produce the "not enough memory" error. This doesn't seem to be
Stephane's issue either, but maybe it is happening on your system.

Another thing I found that was interesting is in a TCP/IP Example that
ships with LabVIEW. Take a look at the "Simple Data Server.vi" Example.
(You can find it by going to Help>>Search Examples>>TCP/IP>>Simple Data
Server) In the block diagram it says "Delay 25ms so we don't flood input
queue on PC's running NT" This phrase makes me think there is something
special about NT (which we obviously know already!). Do you have some sort
of delay in your program to compensate for this flooding? If you do
currently have a delay, what happens if you increase that delay time?

Let me know if any of these things apply to your particular issue. I'll
continue to research this in case the above suggestions don't help.

Regards,

Melissa Garrity

[Stephane 696]

HI Melissa and Dave,

There is my situation regarding the last comments:

1- When the program send me a "not enought ..." error, my sockets are initialized and exchanging together since a while (like 30 secs or more). I can see this by looking on my trace file and also by my current controller state.

2- Looks funny, in the "Simple Data Server", the server send 2 packets... which is the "bug" report by Eric. If Dave made a test based on this example, better modify this 2 packets issue first to be valid. By the way, this is not a real bug. This effect is caused by the fact the NI use an asynchrone socket algorithm under the hood.

3- The client in my case is the one sending the first request to the server. The way my handshake is
done, the client and the server exchange date with read/write. It's not a pure client / server relationship as the NI example.

The socket reporting the problem in my program is not busy at all (one or 2 exchanges / sec). The client dequeue a queued message and send the message by TCP. This loop has a "Wait Until Next ms Multiple" delay of 5 (ms). The server side doesn't have a real delay but a "Wait Until Next ms Multiple" delay of 0 (ms) for the context switching of the thread. I will try to increase the delay time of the client to 25 ms to see if the message go away. maybe the problem can be created by 2 or 3 messages send to quickly.

Have a good evening

Stephane

[Dave Korpi]

Melissa and Stephane:

Thanks for the reply Melissa.

Stephane...

Does look like the error comes from Windows. Also looks like there is
someone at NI who knows about special issues having to do with NT related to
"flooding" This is why Melissa gave the example in the server. Therefore,
the following conclusions to be validated by all:

1) I feel the problem comes from some specific "bug" in Windows NT that does
not exist in Windows 9X. I think it is related to speed but need to have an
exact answer to give customers.

2) The source of the problem is in the SERVER and not the CLIENT. I need
this verified. If this is true it looks like we only have to determine a
delay period to put in the exact right place in our server. I think it needs
to be between the LISTEN and the WRITE. Some of the delay can be taken up by
whast we are writing (for example an analog data acquisition might take 10
of the needed 25 milliseconds). The exact number of milliseconds is not
known.

3) We need to understand, and get clear confirmation on the exact source of
the problem (who is complaining) and what "routine" caused the complaint
(the server in this case?)

My plan of action is to use the Simple Data Server and Simple Data Client
that Melissa refered to and put a control in place of the 25 millisecont
constant, build executables of these two and run them on an NT. I will then
adjust the 25 millisecond control up and down to see if reducing it causes
the "not enough memory..." error and if I increase it we have it go away...

If this comes to pass then we will know there is a relation to the delay and
to the error.

Thanks,

Dave Korpi


THis means that I need to select the proper test code to send to Melissa.


Dave Korpi
22642 Indian Springs Road
Salinas, CA 93908
Phone: (831)-455-0418
Fax: (831)-455-0419
e-mail: korpi@starband.net

----- Original Message -----
From:
To: "Dave Korpi"
Sent: Wednesday, March 06, 2002 8:09 AM
Subject: Re: (Reference#401456) Phone Support E-Mail



Note: Your reference number is included in the Subject field of this
message. It is very important that you do not remove or modify this
reference number, or your message may be returned to you.


Hi Dave,

I've been following the different discussion threads to see if they can
provide any insight. The response by Eric was interesting, but doesn't
seem to be the cause of Stephane's problem...does it sound like yours? I
was thinking that it may have something to do with a connection being
closed, and then doing a read/write to that connection. This should
definitely produce the "not enough memory" error. This doesn't seem to be
Stephane's issue either, but maybe it is happening on your system.

Another thing I found that was interesting is in a TCP/IP Example that
ships with LabVIEW. Take a look at the "Simple Data Server.vi" Example.
(You can find it by going to Help>>Search Examples>>TCP/IP>>Simple Data
Server) In the block diagram it says "Delay 25ms so we don't flood input
queue on PC's running NT" This phrase makes me think there is something
special about NT (which we obviously know already!). Do you have some sort
of delay in your program to compensate for this flooding? If you do
currently have a delay, what happens if you increase that delay time?

Let me know if any of these things apply to your particular issue. I'll
continue to research this in case the above suggestions don't help.

Regards,

Melissa Garrity
Applications Engineer
National Instruments
http://www.ni.com/support

[Dave Korpi]

Stephane and Melissa:

Initial report on the "Not enough memory...." problem:

I went to Detroit Diesel Monday and found that I could get everything to work PERFECT if I used applications written in LabVIEW. It turns out the customer has an application that uses "canned" routines in Visual Basic 6.0 to read and write to the tcp/ip. THese use "standard" Basic and Windows "OCX" files.

The question is" Have others found any incompatability with Visual Basic routines and LabVIEW routines dealing with TCP?IP in an NT environment that do not exist in a Windows 9X environment?

I will be working on this on Wed Mar 13, 2002.

Stephane: Have anything to add to the document below? Any new hints? Are all your applications in LabVIEW? When I make both server and client applications in LabVIEW I see ZERO ERRORS..... I can force the error predictably with a VB6.0 server and LabVIEW client! DOes VB6.0 use a different TCP/IP than LabVIEW? Are the other folks talking about LabVIEW-LabVIEW or "mixed"

Follows is the latest version of Melissa's Document: (Melissa: Have others contributed to the document below? If nobody knows the square root of 2 then send it to an engineer who does then I think we might propogate into the "big wizard" environment...

1. The errors we see only come around on NT so I wonder if there are any NT specific ports that we should stay away from?
There is no information available on Microsoft’s website regarding NT specific ports. The port you are currently using (6341) is listed as unassigned according to the reference below, so the port number should not be an issue here.
http://www.iana.org/assignments/port-numbers

2. Why do you ask about the port number?
I asked about the port number because at first glance of your front panel, I saw a control that was named “port number”. In it was a default value of 1, which would be a restricted TCP/IP port number. I then realized after you sent me the corresponding block diagram that this referred to the serial port number and not the TCP/IP communication port number.

3. Could a wrong port number cause this?
No. (See answer to question 1.)

4. What are the symptoms?
I’m not sure what you’re asking here. If you were asking what the symptoms are of using a “wrong” port number, then it would be a guess. I tried using port 80 for example (reserved for http), and I didn’t get any communication or any error. I also tried using a registered port (3015 for dstp) and communication worked fine.

5. The error is reported by Windows NOT LabVIEW. The error also only appears in Windows NT. The significance of this is:
Writing TCP/IP in a loop is most likely using up all of the connection ports and so the system
"runs out of memory (TCP/IP stack)". It depends on how often you are requesting TCP/IP connections in the system, but basically LabVIEW releases its TCP/IP connection and NT proceeds to hold onto the connection for an additional 240 seconds after we release. If this occurs often enough then the TCP stack can fill up and no more connections are available to handle the request. Take a look at the following MSDN articles. It may be that the Windows NT client is connecting often enough that it runs into these stack issues.

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q149532
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q196271

6. The problem is in Windows NT and not 9X AND is ONLY if the CLIENT is on NT, The SERVER can be on "anything"?
This would have to be tested in order to be verified. My guess is that if either the client or server were on Windows NT this problem would occur since it is the connection between the two that is held by NT for the additional 240 seconds.

7. What are the definitions of “Server” and “Client” as used above in Questions 5 and 6?
The client/server model is a common model for networked applications. In this model, one set of processes (clients) requests services from another set of processes (servers). Another way to think about clients and servers is to use the restaurant analogy. The waiter is a server and you are a client. You ask for the menu, order a meal, and make requests of the waiter similar to the way a client communicates with a server on a network.

8. If it works in Windows 9X and not in NT then we ONLY have to fix the SERVER?
Again, this would have to be tested in order to be verified.


9. Does Windows 9X have the property of holding the connection for an additional 240 seconds?
There was no evidence on MSDN of Windows 9X holding its connection.

10. Why does LabVIEW immediately release the connection and Microsoft hold onto it for this additional 240 seconds?
According to Microsoft’s website: “The TCP/IP-state computer dictates that when a connection is closed, the connection is not released until two maximum segment lives (MSLs) have passed. This state is defined as the Time-wait state. Since one MSL is defined as 120 seconds, it takes four minutes for a closed connection to be released in TCP/IP.” This is a known issue at Microsoft, and therefore, I don’t believe they intended for this prolonged connection.

11. How big is the TCP/IP stack on Windows NT systems?
I haven’t found any definitive information yet on Microsoft’s website.

12. Is there a way to programmatically avoid this error?
The best way to avoid the error is to make the registry changes suggested in Microsoft’s Knowledge Base articles listed above.

13. Does Windows NT have a specific error for running out of TCP/IP stacks?
According to MSDN, there may be an event log created that says “Number of sessions exceeds 2048”. It doesn’t say anything about a definite error created.

14. The term "flooding" refers to what?
I’m not sure what the definition of flooding is, but I do have some new information regarding that message in the example program. The note on the diagram states that there is a 25ms delay in the server VI so that LabVIEW doesn't flood the input queue on Windows NT machines. When the Simple Data Server and Simple Data Client are run on the same NT machine, there are many Windows messages generated due to the data going back and forth. Without the delay, mouse clicks on the front panel will never be detected because they are queued up behind all the other messages and at a lower priority. If this is the case, the VIs will seem to hang. Adding in the delay will prevent this hang, but may or may not get rid of the “not enough memory” error.

15. Does the problem have anything to do with calls to DAQ devices?
This error has been narrowed down to the way Windows NT handles its TCP/IP connections.

16. The problem in this case has nothing to do with "memory leaks" caused by building HUGE arrays.
The question of memory leaks due to build arrays makes no sense in this situation unless you can see memory leaks. Using the NT task manager should provide enough info to determine if this is an issue. I believe that we previously determined that this was not happening.

17. The reason Windows NT reports the error the way it does, as a memory error, is not correct. Windows reports it this way because:
I’m not sure exactly why Windows says that it is a memory error, but it may be referring to the TCP/IP stack filling up.

Thanks,

Dave Korpi
korpi@starband.net

[Kian]

Hi all,

I encountered this same error message so my search for an answer led me to this thread. The problem is I'm not using a tcp/ip connection. All I'm doing is to read an image file from my hard disk, and then process the image. Initially there is no problem but after running the VI for some time, this error message appears. I am running on windows ME.

Please advice. Thanks.