Solved

TIdTCPClient Write - ReadLn

Posted on 2004-08-19
8
2,906 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
 

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
Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

 
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

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

Suggested Solutions

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
Hello everybody This Article will show you how to validate number with TEdit control, What's the TEdit control? TEdit is a standard Windows edit control on a form, it allows to user to write, read and copy/paste single line of text. Usua…
In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…
Illustrator's Shape Builder tool will let you combine shapes visually and interactively. This video shows the Mac version, but the tool works the same way in Windows. To follow along with this video, you can draw your own shapes or download the file…

760 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

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now