🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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

Re: Timeout Issues [Indy 9]

#3035
From: Darlington ADIBE
Date: Fri, 25 Nov 2005 18:16
51 lines
3214 bytes
Remy, thanx alot.

Your comments will surely help me write a better COM,. however from what
your have suggested it looks like i have to rethink my design in view of
both the server and the client.

To help you understand better let me walk you through my design:

The client software connects to the server by calling a COM method "Connect"
at this point only connection is established, the server will not proccess
any cmd from the client if the client is not Authenticated by the client app
calling a COM Authenticate method which then send the UserID and Password to
the server for athentication,

if authenticate pass:
the client is informed and the ThreadID is map to the UserID using a Memory
TStringList "Name=Value" this is how I         check for connections that
have been authenticated.

if authentication fail:
infor client and do nothing else

From above it mean that if i have to reconnect on readtimeout, then i also
have to reauthenticate as the ThreadID = UserID mapping will be invlaid,
since ThreadID changes for every connection "Already the server removes the
ThreadID = UserID mapping when a Thread disconnects"

The Server is actually use to send SMS to Mobile phone through a GSM
Gateway,
When it receives a "SENDSMS" cmd from an authenticated client (here is where
it get complicated)

it first try to send the SMS (this takes some time) at this point the client
is waiting for a status report
if all went well it will send back an "SENDSMS#OK#Msg_ID#" the msg_id is
used by both the client and the server for tracking the msg ie query if the
msg have be received by the receiptant or queqed for delivery by SMSC etc.
the server will then post billing info into a database agaist the UserID

if the operation failed, the server will send "SENDSMS#FAIL#reason#" and
that is all.

from above: if a timeout occures on the client while waiting for the status
report, the client have no way of knowning if the SMS was sent or not, and
it it resend it, it stand the risk of been bill twice for the same msg, even
if I use your idea of disconnecting and reconnecting on timeout the client
will still not know

So I seek for professional advice on this.

Darl.
Technical Details
Message-ID: <438754a8@newsgroups.borland.com>
Path: arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!fr.ip.ndsoftware.net!newsfeed.kamp.net!news.netcologne.de!newsfeed-fusi2.netcologne.de!news-out.newsgroups.com!propagator2-sterling.newsfeeds.com!in.nntp.be!caladan.landsraad.net!newsgroups.borland.com!not-for-mail
References: <43864c38@newsgroups.borland.com> <4386ba83$1@newsgroups.borland.com>

Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,83a059fbd8c24375
X-Google-Attributes: gid11508e,public
X-Google-Language: ENGLISH,ASCII-7-bit
From: "Darlington ADIBE" <bcb@triative.com>
Newsgroups: borland.public.cppbuilder.internet.socket
References: <43864c38@newsgroups.borland.com> <4386ba83$1@newsgroups.borland.com>
Subject: Re: Timeout Issues [Indy 9]
Date: Fri, 25 Nov 2005 19:16:08 +0100
Lines: 53
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
NNTP-Posting-Host: 83.229.68.10
Message-ID: <438754a8@newsgroups.borland.com>
X-Trace: newsgroups.borland.com 1132942504 83.229.68.10 (25 Nov 2005 10:15:04 -0700)
Path: arc1-ca.pugleaf.net!g2news1.google.com!news2.google.com!proxad.net!fr.ip.ndsoftware.net!newsfeed.kamp.net!news.netcologne.de!newsfeed-fusi2.netcologne.de!news-out.newsgroups.com!propagator2-sterling.newsfeeds.com!in.nntp.be!caladan.landsraad.net!newsgroups.borland.com!not-for-mail