Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to access/ run VFP exe file
Message
From
07/10/2002 10:20:15
 
 
To
07/10/2002 01:28:51
General information
Forum:
Visual FoxPro
Category:
Client/server
Miscellaneous
Thread ID:
00708271
Message ID:
00708360
Views:
8
>Dear All,
>
>We have developed a program.. and the requirements, this should run over WAN connection.
>Any idea on how to access a Application EXE program using WAN connection, i tried it already via IP address but the response time is very slow... i want to run my application similar to the response time that im receiving from the local network... any idea on how to enchane this method.
>

Without vastly increasing the bandwidth available over the WAN connection, it will be difficult to radically improve the performance of the app without a major amount of rewriting, or investing in some hardware and software to minimize the data travelling over the WAN.

The most transparent and least code-intensive solutions would tend to use a thin-client solution of some sort; the main site would run Windows Terminal Server or the Citrix enhancements to it, and the Terminal Server box would actually host the application execution. Remote users would log into WTS/Citrix over their WAN connection using an appropriate client (the RDP client built into some versions of Windows (2K, XP Pro), the TSAC (Terminal Services Advanced Client, which comes with WTS and will run on pretty much all Win32 platforms) or the TSAC Browser ActiveX control (runs under IE and requires the WTS to host an instance of IIS) or the Citrix ICA or ICA Web client.) Your Terminal Server would require that you purchase an adequate number of CALs (Client Access Licenses) and perhaps Internet Connection licenses, and the server is shared amongst the remote clients (IOW, depending on the load on the server, you'll likely need it to have very fast processor(s), a more than minimal amount of RAM, and may well consider using more than a single box to host remote clients.) Some OS tuning will be required as well, and the security issues are not insignificant.

A more code-intensive approach would be to implement an n-tier design that moves the business rules and data access layers back to a server on the local site. You would implement these layers as COM components, and access them via DCOM, or alternatively, via Web Services in the .Net environment. If your app is already designed as an n-tier application, you'd move the data-intensive tiers into COM objects run on a local server, using MTS or COM+ if you create .DLLs to implement your COM objects. The User Interface layer would make calls to these COM components to perform specific actions, and would receive back the result set of the requested action, which you would want to minimize in size to minimize the delays in moving data over the WAN. If you routinely work with large datasets in the UI, browsing or displaying thousands of records in grids or the like, you'll want to re-think your UI as well, since doing these things will involve moving tremendous amounts of data over the wire.

To give you an idea of what you're looking at as far as bandwidth, assume that you LAN is using 100Mbps Fast EtherNet. Comparable bandwidth is expensive in a WAN - typical ADSL speeds max out around 1Mbps downlink and 128Kbps-384Kbps downlink, with really fast ADSL around 6Mbps downlink and 384Kbps-1Mbps uplink. A T1 line offers 1.544Mbps of data bandwidth in both directions (24 B channels of 64Kbps each + a 16Kbps D channel) - you're looking at T3 or better to reach near parity, and there's some latency with WANs; delays imposed by things moving over a wire become significant rapidly, and throughput on a packet-switched network like the Internet is generally unpredictable at best, and even with high-speed interconnects can be dog-slow if there's a lot of activity on the Internet backbone.

>Thanks in advance to all :)
>
>Regards
>Reymund
EMail: EdR@edrauh.com
"See, the sun is going down..."
"No, the horizon is moving up!"
- Firesign Theater


NT and Win2K FAQ .. cWashington WSH/ADSI/WMI site
MS WSH site ........... WSH FAQ Site
Wrox Press .............. Win32 Scripting Journal
eSolutions Services, LLC

The Surgeon General has determined that prolonged exposure to the Windows Script Host may be addictive to laboratory mice and codemonkeys
Previous
Reply
Map
View

Click here to load this message in the networking platform