🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: borland.public.cppbuilder.internet.socket
Article #4974

Re: TServerSocket: GetThread() & OnExecute()

#4974
From: Remy Lebeau (TeamB)
Date: Fri, 05 Nov 2004 18:28
66 lines
3872 bytes
"Vladimir Stefanovic" <a@a.com> wrote in message
news:418b7aa7$1@newsgroups.borland.com...

> Why for some requests I send to server my 'HandlingRequests()'
> is executed twice, if I *DO NOT* close the connection in server
> itself, like I did in this example: ClientSocket->Close()?

Because it should.  You set up your code to continuously loop until the
connection is disconnected.  If the client is the one disconnecting the
connection, the server may loop a second time before finally detecting the
disconnect.

Besides, you did not show your code for ReadData(), so it is unclear whether
ReadData() is properly detecting the disconnect, either.  If the client is
only sending 1 packet and then disconnecting, there should be no way your
code is reaching HandlingRequests() twice because only 1 packet is ever
received.  If it is reached twice even though only 1 packet is sent, then
ReadData() is not detecting the disconnect properly and is returning invalid
data in your buffers.  It can't return what was never received in the first
place.

> I do not mean that ClientExecute() is executed twice, I suspect
> that...
>    while ( ( !Terminated ) && ( ClientSocket->Connected ) )
> ...loop continued before I managed to close the connection
> on client side, and so forced HandlingRequests() to do the same
> task that once was completed.

That is not possible unless additional packets were actually received for
processing.  Otherwise, there is a bug in the code that you have not shown
yet.

> I think that is the case because HandlingRequests() f-on
> truncates the COMMAND part of InboxMemortyStream:
>    GET DataToProcess -> becomes -> DataToProcess
> ... and in the second pass
>    DataToProcess -> becomes -> ToProcess

That suggests that there is a bug in your processing code.

> What can I do?

Please show more code.

> Maybe I should try with some flags, to avoid the second pass?

No.  You need to fix the existing bugs that are causing your code to process
things when they shouldn't be.

>                OldSize = InboxMemoryStream->Size;
>                NewSize = OldSize + BufferSize;
>                InboxMemoryStream->Size = NewSize;

Since you are using WriteBuffer() to put the received data into your
TMemoryStream, you do not need to alter the Size manually at all.
WriteBuffer() will do that for you automatically.  Get rid of those three
lines of code altogether.  The only reason to alter the Size manually is if
you were going to pass the TMemoryStream's memory to ReadData() directly,
but you are not doing that.  You are allocating a separate buffer to contain
the received packet data instead, so you actually do not need to use a
TMemoryStream at all.  It is redundant.  Just pass your allocated buffer to
HandleRequests() directly and get rid of the TMemoryStream altogether..


Gambit
Technical Details
Message-ID: <418bc61c$1@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!news.zanker.org!feeder.enertel.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!newsfeed.wirehub.nl!194.72.7.126.MISMATCH!news-peer-test!btnet!newsfeed.bt.es!caladan.landsraad.net!newsgroups.borland.com!not-for-mail
References: <418b7aa7$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,3fbffcd0acc17958
X-Google-Attributes: gid11508e,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com>
Newsgroups: borland.public.cppbuilder.internet.socket
References: <418b7aa7$1@newsgroups.borland.com>
Subject: Re: TServerSocket: GetThread() & OnExecute()
Date: Fri, 5 Nov 2004 10:28:56 -0800
Lines: 68
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
NNTP-Posting-Host: 68.69.17.41
Message-ID: <418bc61c$1@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1099679260 68.69.17.41 (5 Nov 2004 10:27:40 -0700)
Path: arc1-ca.pugleaf.net!g2news1.google.com!news3.google.com!news.glorb.com!news.zanker.org!feeder.enertel.nl!nntpfeed-01.ops.asmr-01.energis-idc.net!newsfeed.wirehub.nl!194.72.7.126.MISMATCH!news-peer-test!btnet!newsfeed.bt.es!caladan.landsraad.net!newsgroups.borland.com!not-for-mail