Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Jun : Re: Telnet error

www.cryer.info
Managed Newsgroup Archive

Re: Telnet error

Subject:Re: Telnet error
Posted by:"Ferenc Nemeth" (ferenc.neme..@interticket.hu)
Date:Thu, 29 Jun 2006 09:46:06

Remy Lebeau (TeamB) wrote:
> "Ferenc Nemeth" <ferenc.nemeth@interticket.hu> wrote in message
> news:44a37aab@newsgroups.borland.com...
>
>> I inserted debug lines in the Check procedure and
>> saw that Response.Count is about 1000.
>
> Why are you sending such large responses to begin with?  What does your
> server code actually look like?  Which version of Indy are you using?

I tried it with a string list too but not good. (loading the file into a
stringlist, then AddStrings) Do not think that the error is because I
working with a file, this error happens some commandhandlers where there
is a stringlist only.

procedure TForm1.TSchGetIniFileCommand(ASender: TIdCommand);
begin
   try
     ASender.Response.LoadFromFile('Server.ini');
   Except
     On E: Exception Do
     begin
       ASender.Response.Clear;
       ASender.Response.Add(E.Message);
     end;
   end;
end;

Version 9.0.18

>
>> then next AThread.Connection.WriteRFCStrings(Response);
>> only sent back about 20 bytes.
>
> That is only possible if the socket is actually erroring, in which case an
> exception would be thrown.  If there is no exception being thrown, then it
> is not possible for it to not be sending all of the data.  Unless the data
> is being intercepted outside of the socket, such as by a firewall/router.

There is some commandhandlers working well. Firewall, router blocks all.
Why OpenWriteBuffer and CloseWriteBuffer solves this problem?

>
>> Yes there is an extra memory buffer that is working for me in
>> a usable application.
>
> By using the write buffering, you are effectivelu doubling the memory usage,
> since your TStrings data is already in memory to begin with.
>
>> I have a previous post.
>
> Please just explain the problem here.  I don't want to go digging around for
> old posts.
>
>> Our main hungarian server is at: www.interticket.hu Two month
>> ago we should change the machine to another. There is a Windows
>> XP english version updated with the last patches. Since this change
>> I cannot use telnet to administrate this server.
>
> Why not?  Please provide more details.  Just changing the OS is not enough
> to cause these kinds of problems.  Something else had to have changed as
> well.

Yes of course, the machine has changed, so changed everything. The main
board, processor, HDD, network card.... only our application server was
not changed.

We install this machine like other our PCs.

>
>> There is about 30 command handler in the telnet server. Some
>> usable some not.
>
> Why are they not usable?  You are not providing any useful details to
> diagnose your problem.

because this error appears. Sending a telnet command and waiting an
answer, but the answer is not full like this:

getinifile
[COMMON]
(the cursor blinking here)

this is not full, because there is more than 30 line in the ini file.
>
>> One of them is listing the ini file of the application server. I know
>> that this function always wrong where this interesting error appears.
>
> How exactly are you sending the data?  Again, please show your actual code.
>
see above

>> I write a test project. Only a form with a telnet server and only 1
>> command handler.  Which lists this server.ini. I can send you this
>> project is you like. I tried it a lot of telnet client, command line or
>> not. If I connect to the telnet server from another machine then the
>> error happens. If I connect to the server from the same machine,
>> there is no error.
>
> Chances are, your code is not sending the data properly to begin with.  So
> again, please show the actual code.
>
> On the other hand, you still haven't provide any details about the actual
> error you are getting.  Please do so.
>
you did not understand me! There is no error! After a telnet command
comes back a chunk of the full answer.
>
> Gambit
>
>

Feri

Replies:

In response to:

www.cryer.info
Managed Newsgroup Archive