🚀 go-pugleaf

"Roberto Zais" <rzaiss@tiscali.it> wrote in message
news:42e010be$1@newsgroups.borland.com...

> [Rarely I notice  errors, They are rare but persistent ..( Connection
> refused)

"Connection refused" means that either 1) the server is not running, or 2)
it has too many pending client requeusts and can't accept anymore until it
handles the ones that are already pending.

> TCPClient->ReadTimeout = 100;            //READ_STACK_TIMEOUT;

Why are you setting that every time the function is called?  You don't need
to.  Just set it once before calling Connect().  Or better yet, don't set it
at all.  Pass your timeout to ReadFromStack() directly instead of
IdTimeoutDefault.

>         if(TCPClient->InputBuffer->Size  == 0 )
>                 size_readable =
> TCPClient->ReadFromStack(true,IdTimeoutDefault,true);
>               else
>                 size_readable = TCPClient->InputBuffer->Size;
>         }

>        catch(Exception& e){       // Without display

Always catch exception by 'const' references:

    catch(const Exception& e){       // Without display

>           String sbuf = String(e.ClassName()) + " " + e.Message.c_str();

Don't use c_str() like that:

    String sbuf = String(e.ClassName()) + " " + e.Message;

>           if (String(e.ClassName()) == "EIdReadTimeout")
>                   return;                 // lets in waiting read loop

That is not a good way to handle exception testing.  If you want to know if
an exception is a particular class type, then you should be using
dynamic_cast instead:

    if (dynamic_cast<EIdReadTimeout*>(&e) != NULL )

Better would be to catch the specific exception type directly instead:

    catch(const EIdReadTimeout &)
    {
        return;
    }

Better would be to not throw an exception at all.  Specify False instead of
True for the ARaiseExceptionOnTimeout parameter of ReadFromStack().  That is
what the earlier code sample was doing.

>     if(ser_start <= ser_end)
>                                             // circular buffer
>          size = Min((ser_end + MAX_BUF - ser_start),size_readable);
>             else
>                                             // buffer disposto linearmente
:
>                                             // spazio libero = semplice
> differenza puntatori
>          size = Min((ser_end - ser_start),size_readable);    // al limite,
> zero

How EXACTLY are your packets actually formatted?  It doesn't look like you
are taking the advice of the earlier code sample:

    "I would strongly recommend that you prefix your packets with the actual
size of the packets.  Then you don't have to limit your buffer size during
reading, and can send small and large packets alike"

>     TCPClient->ReadBuffer(buf, size);
> // are possible any errors in this phase  ???

No, if the InputBuffer actually has the specified number of bytes available.
If it doesn't, then it has to call ReadFromStack() again (as well as
CheckForDisconnect()) to read more bytes, and that can potentially throw
exceptions.


Gambit

First of all , please,  I have a question :  is  TCPClient->Disconnect();
innocuous  even if already disconnected , too ??
I didn' t find this information in the help.

> Better would be to not throw an exception at all.  Specify False instead
of
> True for the ARaiseExceptionOnTimeout parameter of ReadFromStack().  That
is
> what the earlier code sample was doing.

so, I have modified the code in this way :

try     {
        if(TCPClient->InputBuffer->Size  == 0 )
                size_readable = TCPClient->ReadFromStack(true,100,false);
              else
                size_readable = TCPClient->InputBuffer->Size;
        }
       catch(const Exception& e){
          String sbuf = String(e.ClassName()) + " " + e.Message;
          MessageText = sbuf;    //  for only eventually debug info
          return;                         // all exception in this phase :
return (wait loop)
                                            //  ( there is a global timeout
on the RX operation)

          }
if(!size_readable)
        return;

else:  ......  acquisition of data

Now, I don' t experiment(by debugging) any return by exception: which other
exception are possible , except rxtimeout?
I remember at the beginning, I set the try-catch because it seemed that in
presence of a bad condition ( typically
read timeout)  the size returned  by TCPClient->ReadFromStack was bad and I
got blockings and bad
results .
What does it happen if I remove the try-catch and set
TCPClient->ReadFromStack(true,100,false);  ?
Is size_readable really  reliable ?


>
> How EXACTLY are your packets actually formatted?  It doesn't look like you
> are taking the advice of the earlier code sample:
>
>     "I would strongly recommend that you prefix your packets with the
actual
> size of the packets.  Then you don't have to limit your buffer size during
> reading, and can send small and large packets alike"
>

Yes, the only reason is that I fear disalignment . But ,really ,there is not
a difference concerning disalignment .
My packets begin with 0x16 and end with 0x4  all other is ASCII char.
When the first byte is lost is lost and the re align procedure is the same .
More, through a TCP conn.
nothing should be lost.

On the whole, is this solution  the more common and fast?
Using streams may be better or not ?

Thanks, very much , for your help

Roberto

"Roberto Zais" <rzaiss@tiscali.it> wrote in message
news:42e0c5b2@newsgroups.borland.com...
> First of all , please,  I have a question :  is  TCPClient->Disconnect();
> innocuous  even if already disconnected , too ??
> I didn' t find this information in the help.

> so, I have modified the code in this way :

You did not pay attention to what the earlier code was doing.  Remove the
try..catch, and size_readable will be -1 on timeout so (!size_readable) will
not work.  Use (size_readable < 1) instead.

> I remember at the beginning, I set the try-catch because it seemed
> that in presence of a bad condition ( typically read timeout)  the size
> returned  by TCPClient->ReadFromStack was bad and I got blockings
> and bad results .

That is because you are not checking the size properly.

> Is size_readable really  reliable ?

Yes.  It returns how many bytes the socket actuall returned and Indy then
buffered for later reading.

> Yes, the only reason is that I fear disalignment . But ,really ,there
> is not a difference concerning disalignment .

What are you talking about?

> My packets begin with 0x16 and end with 0x4

That is fine, though including the packet size insode each packet as well
would be better.

With that said, since your packets are already framed, I would suggest not
calling ReadBuffer() until you have first validated that all of the packet
data is actually available.  For example (untested):

    TCPClient->Host = iaddress;
    TCPClient->Port = iport;
    TCPClient->ReadTimeout = 100;
    TCPClient->Connect(0);

    void __fastcall TContactThread::socket_read_procedure(void)
    {
        int size_readable = TCPClient->ReadFromStack(true, IdTimeoutDefault,
false);
        if( size_readable == -1 )
            return;

        do
        {
            char *ptr = (char*) TCPClient->InputBuffer->Memory();

            int start = MemoryPos("\x16", ptr,
TCPClient->InputBuffer->Size);
            if( start < 1 )
            {
                TCPClient->InputBuffer->Clear();
                break;
            }

            int end = MemoryPos("\x4", ptr+start,
TCPClient->InputBuffer->Size - start);
            if( end < 1 )
                break;

            if( start > 1 )
                TCPClient->InputBuffer->Remove(start-1);

            int size = ((end-start)+1);
            char *buf = new char[size];

            TCPClient->ReadBuffer(buf, size);

            // use buffer as needed...
            delete[] buf;
        }
        while( TCPClient->Connected() );
    }

> When the first byte is lost

TCP/IP guarantees data integrity.  If data is corrupted, then something is
wrong with the socket in general and it should be reporting errors anyway.


Gambit

Great!  many thanks, Remy .

> > First of all , please,  I have a question :  is
TCPClient->Disconnect();
> > innocuous  even if already disconnected , too ??
Have you please an answer about this?   Actually there is the  risk I close
more times
the connection . Is it allowed ?
thanks
Roberto

"Roberto Zais" <rzaiss@tiscali.it> wrote in message
news:42e165a4@newsgroups.borland.com...

> Have you please an answer about this?   Actually there
> is the risk I close more times the connection . Is it allowed ?

You could have just looked at Indy's source code for that answer.

Yes, you can call Disconnect() multiple times.  If you have multiple threads
involved, though, then I suggest you protect access to the connection so
that threads do not access it at the same time.


Gambit

Thank you very much for your answer, Remy

Roberto

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> ha scritto nel messaggio
news:42e1750b$1@newsgroups.borland.com...
>
> "Roberto Zais" <rzaiss@tiscali.it> wrote in message
> news:42e165a4@newsgroups.borland.com...
>
> > Have you please an answer about this?   Actually there
> > is the risk I close more times the connection . Is it allowed ?
>
> You could have just looked at Indy's source code for that answer.
>
> Yes, you can call Disconnect() multiple times.  If you have multiple
threads
> involved, though, then I suggest you protect access to the connection so
> that threads do not access it at the same time.
>
>
> Gambit
>
>