TCP ReadSocket Timeout

[trevx15]

Hi all,

I have two questions I am hoping someone might have some information on.

1. I remembered reading somewhere on this forum that you could set the ReadSocket timeout to 0 to help reduce latency and allow the MSG instruction to behave a bit differently/better. The timeout I am referring to is the one inside the MSG instruction that has the service type of ReadSocket and then uses a source element that has a specified timeout.

2. The main issue I am trying to solve is a TCP client connection that will receive variable length data from a TCP server would ideally read until it hits a delimiter character, in my case carriage return, line feed ($n$l). However I realize doing this might not be super straight forward because TCP is a data stream that is primarily based around byte size.

Thank you!

 

[Contr_Conn]

Q1. Yes, you can set this parameter to 0 and it will return data without waiting.
However, I personally prefer to use a number that is equal to the task period, because 0 is not described in any manuals.
Please note that most likely you will be reading an empty buffer most of the time.
The response to the empty buffer is different for UDP and TCP.
Also there is TCP response difference in V35 and some EN4TRs that was corrected in V36.

Q2. My usual approach is to bring all incoming TCP packets blindly (unconditionally) into one large buffer, then separately parse this buffer.
In your case it will be searching for $n$l.
You can check some Sample applications (for example Modbus TCP AOI) to see how it's done there.

 

[trevx15]

Thank you for your response!
I am pretty sure you were the one that had a forum response talking about setting the timeout to 0.

To ensure you are not relying on the timeout, would you set the buflen to less than the shortest piece of data ever expected?
And append that data to your one large buffer which is only cleared after the data is parsed?
I want to make sure I am not hurting the responsiveness of the communication.

 

[Contr_Conn]

I can't answer it, I don't remember details to advise.

I don't like that Read will sit and wait for a data, holding the socket and preventing Writes.
I am using quick reads and not waiting for data.
No data - move on.
If data is there, then add it to the buffer.

I found this way to be the most efficient back in 2005 when sockets were introduced and using it since.

 

[trevx15]

No worries at all!

I am using the rockwell provided SKT_AOI_TCP_CLIENT and I am realizing it has some significant limitations specifically for my application where I will only be reading something after I first write something to the socket and since the AOI is constantly executing the read command to see if any data shows up, then the timeout becomes a delay that harms the responsiveness of my write commands.

Thank you again, this really helped me process through this stuff.

 

[Contr_Conn]

I recall seeing this AIO, but I never used it my applications, can't comment