In my TIdTCPServer.OnConnect event, I receive information using:
AContext.Connection.IOHandler.ReadLn(LF, 5000)
I've read that ReadLn() expects LF on the end of strings, so do I need to add a LF at the end, like this?
TCPClient.IOHandler.WriteLn('TEXT' + LF);
I see in WriteLn() it already include that automatically:
procedure TIdIOHandler.WriteLn(const AOut: string;
AByteEncoding: IIdTextEncoding = nil
{$IFDEF STRING_IS_ANSI}; ASrcEncoding: IIdTextEncoding = nil{$ENDIF}
);
begin
// which encodes a LF character to byte $25 instead of $0A (and decodes
// byte $0A to character #$8E instead of #$A). To account for that, don't
// encoding the CRLF using the specified encoding anymore, force the encoding
// to what it should be...
//
// But, what to do if the target encoding is UTF-16?
{
Write(AOut, AByteEncoding{$IFDEF STRING_IS_ANSI, ASrcEncoding{$ENDIF);
Write(EOL, Indy8BitEncoding{$IFDEF STRING_IS_ANSI, Indy8BitEncoding{$ENDIF);
}
// Do as one write so it only makes one call to network
Write(AOut + EOL, AByteEncoding
{$IFDEF STRING_IS_ANSI}, ASrcEncoding{$ENDIF}
);
end;
As you noted,
IOHandler.WriteLn()automatically sendsEOL(akaCRLF) at the end of each string. This is because most textual Internet protocols useCRLF.IOHandler.ReadLn()expectsLFby default if you omit the terminator, but whenever the terminator isLF(implicitly or explicitly) thenIOHandler.ReadLn()will also handleCRLFas well. So, DO NOT pass in your ownLFtoIOHandler.WriteLn(), eg:If you want to send
LFinstead ofCRLF, useIOHandler.Write()instead, eg: