Article View: borland.public.cppbuilder.internet.socket
Article #5539Unable to re-set Active property of TIdUDPServer
From: Lesley Anne
Date: Mon, 02 Aug 2004 15:23
Date: Mon, 02 Aug 2004 15:23
37 lines
3147 bytes
3147 bytes
I have a server application that listens for customer queries coming in over IP (both TCP and UDP), checks databases, and then sends back an answer. Occasionally there are times (like when it loses connectivity to a remote database, or when doing admin/maintenance on a local database) when the application needs to temporarily close those server ports in order to force clients over to an alternate site running another instance of the application. Then when the situation is back to normal, it needs to re-open the server ports. This works fine for TCP (using a TServerSocket component and its Close and Open methods), but now we're adding UDP access to the application, and I've found that once the UDP socket is closed, the application can't re-start it. I'm using a TIdUDPServer component (from the Indy components that came with Builder 6). I've tried setting its Active property false and then true again. Setting it false works and we stop receiving the incoming UDP packets, but then when we set it back to true we should start seeing the incoming packets again but never do. (Setting Active to true is in a try-catch block, but no exception is raised.) The only way we've found to recover the UDP server socket is to manually shut down the whole application and then re-start it, which is not a viable solution. I've now tried a partial solution where instead of disabling and then re-enabling the component, I simply set a global variable that tells the application to temporarily ignore incoming UDP messages and not respond to them. This works fine for instances where the application has explicitly shut down UDP access, but we've now found that there are some instances (usually when we have a lot of traffic and the PC gets busy for a while) that we seem to lose the UDP port even without having explicitly told it to stop listening. These instances are more problematic. We've already established that the application doesn't seem to be able to re-set the UDP port, so how can I make it recover from these cases when it stops receiving the UDP packets which are being sent to it? (And what's really happening here anyway? Why does the UDP port seem to just go away like that?) Lesley Anne
Technical Details
Message-ID:
<410e5bb3$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!news.glorb.com!cox.net!news-xfer.cox.net!in.100proofnews.com!in.100proofnews.com!nntp.infostrada.it!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mailShow Full Headers
Complete Article Headers
X-Google-Thread: 11508e,e31ef7362b0ac137,start X-Google-Attributes: gid11508e,public X-Google-Language: ENGLISH,ASCII-7-bit From: "Lesley Anne" <labaker@snetnsa.REMOVE-THIS-BIT.com> Newsgroups: borland.public.cppbuilder.internet.socket Subject: Unable to re-set Active property of TIdUDPServer Date: Mon, 2 Aug 2004 11:23:18 -0400 Lines: 40 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 NNTP-Posting-Host: 204.60.2.44 Message-ID: <410e5bb3$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1091460019 204.60.2.44 (2 Aug 2004 08:20:19 -0700) Path: arc1-ca.pugleaf.net!g2news1.google.com!news1.google.com!news.glorb.com!cox.net!news-xfer.cox.net!in.100proofnews.com!in.100proofnews.com!nntp.infostrada.it!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail