TCP connection closed by peer

[hankypanky]

I noticed some posts already discussing Error 66 associated with TCP Read, but none seem to cover the question I have.  So, here I go... I have a TCP server in Labview which just reads from the TCP connection (it reads FRAMESZ bytes a time).  But let's say I don't know the size of the data I'm sending from the client beforehand.  Say N-1 frames have been sent, and then, the client reaches the last (Nth) frame, which it proceeds to send and then, right afterward, it closes the connection.  The server doesn't know that Nth frame was the last frame, so, upon receiving that frame via TCP Read, it then calls TCP Read again to receive another ((N+1)th) frame.  But the client has closed the connection, so that (N+1)th TCP Read in the server throws an Error 66, indicating the connection was cloed by the peer.  How can this be avoided?  Currently, I add one extra byte to the start of the frame: a 0 indicates this IS NOT the last frame an a 1 indicates this IS the last frame.  Then, when the server encounters a frame beginning with a 1, it knows to not call TCP Read again.  However, this adds (a small amount of) overhead to the communication.  Is there any other way to handle this nasty situation?  In C, recv() simply returns 0 when the peer has closed() -- is there no equivalent to this functionality in Labview??

[smercurio_fc]

What is it that you're trying to prevent? The read operation, or the error? To prevent the read operation the server needs to know if it's received the last chunk of data, and basically it has to know how much to get. If you're trying to prevent the error, just look at the error coming out of the TCP Read and then see if it's 66. If so, simply null out the error, sort of like this:

Message Edited by smercurio_fc on 09-27-2007 09:07 AM

[BillMe]

I like using the enumerated constant and comparing against several error conditions to see if my TCP/IP connection is still valid. Then, as smercurio says, you can choose to ignore it or act on it. From the Simple Data Client.vi example:

Message Edited by Bill@NGC on 09-27-2007 10:02 PM

[smercurio_fc]

Thanks for pointing out the alternative solution, Bill. I have to admit I don't have that much familiarity with the error functions that NI provides with LabVIEW because I have my own set of error functions. <personal opinion>I've always found the error functions in LabVIEW quite lacking and not all that useful for large programs. If NI were really serious about error handling they would provide a rich set of error functions in their own palette, rather than burying them inside the "Dialog and User Interface" palette. "DIalog and User Interface"??? Really? </personal opinion>

[BillMe]

No product is perfect, but you have to admit that NI does an excellent job of listening to their customers, so I'd take advantage of that...I do.