The code shown doesn't account for the delimiter bytes in the case that they're stripped out separately, unless you've already done that elsewhere. Basically, in that case you would want to add :STRINGLEN into :RETURNSIZE before running this code (but after rlrBuffCount and rlrBuffSize are set to :RETURNSIZE). Other than that, it looks OK to me.
I’ve recently run into something that I think is probably the same issue Ewen was experiencing. In my code, I was getting an intermittent but fairly frequent issue where the returned data in an HTTP response would be corrupt, generally with good data at the beginning but then another partial copy of the same data after it. I did some debugging on this issue, and I’m pretty sure I’ve tracked down the cause of it. In brief, it may occur if the caller uses TCPIPReadLineTCP and then subsequently uses...
TCPIPConvertIPToHex not parsing port number
In something I've been working on recently, I've run into an instance of this issue with more problematic effects. In brief, when Marinetti has one or more active TCP connections but it processes an incoming TCP packet that is not from any of those connections, it will generally send out a TCP RST packet to one of the active connections, which may result in terminating that connection. This can also happen when packets come in or are processed from a previous valid connection that has been aborted...