xor_cowboy
asked on
TIdTCPClient Write - ReadLn
I hope anybody can help. Here is our problem.
We are using D6 and D7 with Indy 9.0.14 / Indy 9.0.17 and Ethereal to analyze the send/receive packages over the network. We use similar code in one of our projects and we are facing some problems. The TCPClient in the code is connected and is ready to send or receive. The TCPClient is used in a client application.
.
.
Delimiter := #$0D#$0A;
DeviceCommand := 'ABCD';
ReplyTimeOut := 2000;
.
.
TCPClient.Write( DeviceCommand + Delimiter);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
The sample code works fine if the reply from the server is being sent in only one package. Unfortunately, we are not able to tell the server to send the reply in only one package. Our server generates 4 packages and send all packages over the net (e.g. '0', '1', #$0D, #0A). We checked with Ethereal the packages and all packages are sent and received correctly. If we use the same sample code with our server we run into a timeout (we know that we received all packages under the 2000ms timeout limit). If we change the code and use a sleep between write and ReadLn we receive a correct reply.
.
.
TCPClient.Write( DeviceCommand + Delimiter);
sleep(50);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
If we set the Delimiter to #$0A or #$0D we receive a reply without a timeout (we set the Delimiter in the server to the same value). Our guess is, that we are not using Indy correctly. Does anybody know why Indy is making trouble? Any help is appreciated.
By the way, while testing with the IDE debugger we noted that Indy components are working correctly. As a regular compiled application we have the problems described above.
Please ask if you need more information.
We are using D6 and D7 with Indy 9.0.14 / Indy 9.0.17 and Ethereal to analyze the send/receive packages over the network. We use similar code in one of our projects and we are facing some problems. The TCPClient in the code is connected and is ready to send or receive. The TCPClient is used in a client application.
.
.
Delimiter := #$0D#$0A;
DeviceCommand := 'ABCD';
ReplyTimeOut := 2000;
.
.
TCPClient.Write( DeviceCommand + Delimiter);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
The sample code works fine if the reply from the server is being sent in only one package. Unfortunately, we are not able to tell the server to send the reply in only one package. Our server generates 4 packages and send all packages over the net (e.g. '0', '1', #$0D, #0A). We checked with Ethereal the packages and all packages are sent and received correctly. If we use the same sample code with our server we run into a timeout (we know that we received all packages under the 2000ms timeout limit). If we change the code and use a sleep between write and ReadLn we receive a correct reply.
.
.
TCPClient.Write( DeviceCommand + Delimiter);
sleep(50);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
If we set the Delimiter to #$0A or #$0D we receive a reply without a timeout (we set the Delimiter in the server to the same value). Our guess is, that we are not using Indy correctly. Does anybody know why Indy is making trouble? Any help is appreciated.
By the way, while testing with the IDE debugger we noted that Indy components are working correctly. As a regular compiled application we have the problems described above.
Please ask if you need more information.
ASKER
>> but have you tried using WriteLn instead of Write
>> TCPClient.Write( DeviceCommand);
Thanks for the reply. As you can see in TIdTCPConnection.pas WriteLn is wrapping the write procedure with an EOL. No difference. I checked with Ethereal and TidTCPConnection.Write is sending the DeviceCommand+Delimiter correctly to the server. The server correctly replies unfortunately in four separate packages. So, my guess is that TIdTCPConnection.ReadLn (input buffer) is the trouble maker.
>> TCPClient.Write( DeviceCommand);
Thanks for the reply. As you can see in TIdTCPConnection.pas WriteLn is wrapping the write procedure with an EOL. No difference. I checked with Ethereal and TidTCPConnection.Write is sending the DeviceCommand+Delimiter correctly to the server. The server correctly replies unfortunately in four separate packages. So, my guess is that TIdTCPConnection.ReadLn (input buffer) is the trouble maker.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I was debugging today and I had a similar idea. Here is what I did (sorry just code snippet from project)
..
PNodeData(Node.Data).dvTCP
..
PNodeData(Node.Data).dvTCP
if ReplyEndDelimiter = EOL then
begin
// quick fix for Indy behavior
// still Indy ignores 0x0D in the reply
ReplyString := PNodeData(Node.Data).dvTCP
end
else
begin
ReplyString := PNodeData(Node.Data).dvTCP
...
end;
Works fine. But it does not explain why I run into the problem if the server reply is cut apart into e.g. four frames. I wrote a test server with Indy compenents to emulate the real server. The Indy Server sends one package and the original code works.
See original demo code
.
.
Delimiter := #$0D#$0A;
DeviceCommand := 'ABCD';
ReplyTimeOut := 2000;
.
.
TCPClient.Write( DeviceCommand + Delimiter);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
As you might understand I was getting very stressed because I did not see a difference in my emulation server and the real server (just the frames counts). If you can give me a good answer to this part of the problem I will accept and close the question.
..
PNodeData(Node.Data).dvTCP
..
PNodeData(Node.Data).dvTCP
if ReplyEndDelimiter = EOL then
begin
// quick fix for Indy behavior
// still Indy ignores 0x0D in the reply
ReplyString := PNodeData(Node.Data).dvTCP
end
else
begin
ReplyString := PNodeData(Node.Data).dvTCP
...
end;
Works fine. But it does not explain why I run into the problem if the server reply is cut apart into e.g. four frames. I wrote a test server with Indy compenents to emulate the real server. The Indy Server sends one package and the original code works.
See original demo code
.
.
Delimiter := #$0D#$0A;
DeviceCommand := 'ABCD';
ReplyTimeOut := 2000;
.
.
TCPClient.Write( DeviceCommand + Delimiter);
DeviceReply := TCPClient.ReadLn(Delimiter
.
.
As you might understand I was getting very stressed because I did not see a difference in my emulation server and the real server (just the frames counts). If you can give me a good answer to this part of the problem I will accept and close the question.
I am not sure. But I have had issues before which is why I tend not to use write and writeln. I don't like the way they convert the string to a pointer. I also had issues in a server. (large production one) where we were getting random errors and memory issues. The moment we stopped using write things worked ok. It may have to do with string typecasting and specific compiler options.
LOutLen := Length(AOut);
if LOutLen > 0 then begin
WriteBuffer(Pointer(AOut)^
end;
I always use writebuffer.
ie
s := AThread.Connection.ReadLn;
s := s+#13#10;
AThread.Connection.WriteBu
and this took away many strange issues. Please try this option yourself.....
LOutLen := Length(AOut);
if LOutLen > 0 then begin
WriteBuffer(Pointer(AOut)^
end;
I always use writebuffer.
ie
s := AThread.Connection.ReadLn;
s := s+#13#10;
AThread.Connection.WriteBu
and this took away many strange issues. Please try this option yourself.....
ASKER
Pointer(AOut)^ and s[1] - looks similar to me. s[1] is a nice C flavour...well s[0]
Anyway, I think I was not clear enough. I'm figthing with the client. the problem is here:
..
DeviceReply := TCPClient.ReadLn(Delimiter
..
If my client receives a reply in one frame DevicedReply is not empty and everything is fine. If my client receives a reply in more than one frame (well, I must be honest - 4 frames, one byte data each frame) ReadLn gives me a timeout and DeviceReply is empty. The fix we discussed earlier is good. But for future use I want to know why I get in trouble with ReadLn.
Anyway, I think I was not clear enough. I'm figthing with the client. the problem is here:
..
DeviceReply := TCPClient.ReadLn(Delimiter
..
If my client receives a reply in one frame DevicedReply is not empty and everything is fine. If my client receives a reply in more than one frame (well, I must be honest - 4 frames, one byte data each frame) ReadLn gives me a timeout and DeviceReply is empty. The fix we discussed earlier is good. But for future use I want to know why I get in trouble with ReadLn.
I don't know why to be honest. because when i try sending it with multiple frames it works fine. Sorry.
pointer(AOut)^ is fine for a pchar... but delphi long strings are memory managed. with a delphi short string byte 0 s[0] was the length byte and s[1] was the address of the first byte of data.
when you do pointer(AOut)^ it has to convert the long string buffer into a pchar. long strings are memory managed objects in delphi where the compiler has to do nifty things to make stuff work in the background.
as i said.... when using write in indy with their method on a 24/7 server we got issues. when the only change in the application was removing the write and using writebuffer directly as specified our weirdness disappeared. (This is a simple observation)
all the best
pointer(AOut)^ is fine for a pchar... but delphi long strings are memory managed. with a delphi short string byte 0 s[0] was the length byte and s[1] was the address of the first byte of data.
when you do pointer(AOut)^ it has to convert the long string buffer into a pchar. long strings are memory managed objects in delphi where the compiler has to do nifty things to make stuff work in the background.
as i said.... when using write in indy with their method on a 24/7 server we got issues. when the only change in the application was removing the write and using writebuffer directly as specified our weirdness disappeared. (This is a simple observation)
all the best
ASKER
Sorry for misunderstanding. My meaning was that in C you start with s[0]. That Delphi requires s[1] is clear because strings have their length in s[0] and are not null terminated.
Multiple frames:
I write a little service with a TIdTCPServer component and pushed Indy to send at least two frames. Delimiter is #$0A#$0D. With this code in the client I ran into a timeout.
DeviceReply := TCPClient.ReadLn(Delimiter
With the code fix we discussed earlier ( just the ReadLn) everything is running smooth. As long as I know that I might run into problems I can be careful and do better testing. So let me accept and give you the credit because you invested time and offered a workable solution.
Thanks for the eye-opener "writebuffer". I think that writebuffer trick can save me a lot of time with my next Server. If I need help for my future projects I know who to contact.
Multiple frames:
I write a little service with a TIdTCPServer component and pushed Indy to send at least two frames. Delimiter is #$0A#$0D. With this code in the client I ran into a timeout.
DeviceReply := TCPClient.ReadLn(Delimiter
With the code fix we discussed earlier ( just the ReadLn) everything is running smooth. As long as I know that I might run into problems I can be careful and do better testing. So let me accept and give you the credit because you invested time and offered a workable solution.
Thanks for the eye-opener "writebuffer". I think that writebuffer trick can save me a lot of time with my next Server. If I need help for my future projects I know who to contact.
TCPClient.Write( DeviceCommand);