TCP Read Queue

[Mister_Rose]

I am trying to implement a TCP Read Line function that can handle a variety of line terminations (CR, LF, CR+LF). In order to do this I need to be able to look at the next byte in the queue, without dequeing it.

I can read one byte at a time and when I detect either a CR or a LF. When I get there I stop reading and return the line for processing.

If a program sends a CR+LF sequence, this would result in a blank line being sent for processing. This is not a huge issue, as the logic can just ignore blank lines, but it would be nice to be able to look into the buffer and if the next byte is a LF, then read it.

I've worked with other networking stacks that allow you to peek into the buffer without dequeuing it, but I do not see this functionality in Labview. Maybe it is buried somewhere?

[Sam_Sharp]

Read the bytes into a string buffer and then process them from there:

Your 'search' function can choose when to exit, you could wait until the next iteration of the loop to see if the next character is one of the other linefeed characters.

[Mister_Rose]

The problem with that comes when there is a non EOL character that gets read after the EOL.

Assuming the handler is outside of your loop, there would have to be another wire that takes that character and feeds it back into the shift register.

It can be done that way, but I want to keep stray wires to a minimum.

[Sam_Sharp]

It's an uninitialised shift register - it will keep the history between executions. I guess in my 'search for termination' SubVI, there should be another output which returns the message/command - the wire I've shown going back into the shift register should be what's left in the buffer after you've found your search criteria (e.g. a non-EOL character after an EOL character match)

[CoastalMaineBird]

Sam's basic idea is correct - do the buffering yourself and search for whatever termination is appropriate.

The ShiftReg holds the buffer from one call to the next.

When you find a terminator, extract the line before it to deliver to the caller, and return any remainder to the ShiftReg.

I would change the call to TCP READ to read all available bytes, though. Chances are, you get a packet at a time, and there's no reason to force the OS to deliver bytes one at a time.

[Sam_Sharp]

---

@CoastalMaineBird wrote:

I would change the call to TCP READ to read all available bytes, though. Chances are, you get a packet at a time, and there's no reason to force the OS to deliver bytes one at a time.

---

Well spotted - I knew you couldn't wire '-1' or '0' to the bytes to read but had forgotten that using the 'Immediate' mode will return any bytes if they are there immediately rather than waiting until timeout.

[CoastalMaineBird]

Here is my code to do the buffering part.

You call this with a buffer, a NEW DATA string, and the terminator to search for.

It appends the NEW DATA to the buffer, and searches for the terminator.

If found, it returns the line (before the terminator), in the LINE OUT slot, and it is removed from the buffer.

If not found, the buffer now includes the new data, and you try again later.

The caller uses the LINE OUT being empty as a signal that no line is available.  If blank lines are a possibility, use a separate boolean output.