Article View: borland.public.cppbuilder.internet.socket
Article #3035Re: Timeout Issues [Indy 9]
From: Darlington ADIBE
Date: Fri, 25 Nov 2005 18:16
Date: Fri, 25 Nov 2005 18:16
51 lines
3214 bytes
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-mailReferences:
<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