Solved

TIdTCPClient Write - ReadLn

Posted on 2004-08-19
8
2,936 Views
Last Modified: 2007-12-19
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, ReplyTimeOut);
.
.

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, ReplyTimeOut);
.
.

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.
0
Comment
Question by:xor_cowboy
  • 4
  • 3
8 Comments
 
LVL 13

Expert Comment

by:BlackTigerX
ID: 11843124
it shouldn't make a difference (apparently), but have you tried using WriteLn instead of Write

TCPClient.Write( DeviceCommand);
0
 

Author Comment

by:xor_cowboy
ID: 11844519
>> 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.

0
 
LVL 3

Accepted Solution

by:
KyleyHarris earned 260 total points
ID: 11848767
Readln has special code checking to support readln linux or windows. this is why the default delimiter is #10 ($0A), but when this is found, if the preceding character is #13 ($0d) then it will strip this also. Try Readln with the standard Delimiter and let us know if this works
0
Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

 

Author Comment

by:xor_cowboy
ID: 11849032
I was debugging today and I had a similar idea. Here is what I did (sorry just code snippet from project)

..
PNodeData(Node.Data).dvTCPClient.Write(SendData);
..

 PNodeData(Node.Data).dvTCPClient.ReadTimeout := ReplyTimeOut;

        if ReplyEndDelimiter = EOL then
        begin
          // quick fix for Indy behavior
          // still Indy ignores 0x0D in the reply
          ReplyString := PNodeData(Node.Data).dvTCPClient.ReadLn;
        end
        else
        begin
          ReplyString := PNodeData(Node.Data).dvTCPClient.ReadLn(ReplyEndDelimiter);
         ...
        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, ReplyTimeOut);
.
.

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.  

0
 
LVL 3

Expert Comment

by:KyleyHarris
ID: 11849100
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)^, LOutLen);    
  end;

I always use writebuffer.

ie
  s := AThread.Connection.ReadLn;
  s := s+#13#10;
  AThread.Connection.WriteBuffer(s[1],length(s));

and this took away many strange issues. Please try this option yourself.....
0
 

Author Comment

by:xor_cowboy
ID: 11849335
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, ReplyTimeOut);
..

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.
0
 
LVL 3

Expert Comment

by:KyleyHarris
ID: 11849396
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
0
 

Author Comment

by:xor_cowboy
ID: 11852908
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, ReplyTimeOut);

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.
0

Featured Post

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article explains how to create forms/units independent of other forms/units object names in a delphi project. Have you ever created a form for user input in a Delphi project and then had the need to have that same form in a other Delphi proj…
Introduction Raise your hands if you were as upset with FireMonkey as I was when I discovered that there was no TListview.  I use TListView in almost all of my applications I've written, and I was not going to compromise by resorting to TStringGrid…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Although Jacob Bernoulli (1654-1705) has been credited as the creator of "Binomial Distribution Table", Gottfried Leibniz (1646-1716) did his dissertation on the subject in 1666; Leibniz you may recall is the co-inventor of "Calculus" and beat Isaac…

808 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question