Hello all - received this from a client, any suggestions? OI 4.1.3 with the UD.

"Our tablet PC is unusably slow when connected to our server using Verizon's broadband service and a virtual private network. Although web browsing and downloading files from our server is reasonably fast, running our OI application on our server creates too much network traffic."

TIA,

Mike O.

Mike -

They should look at using a thin client like Terminal Services, or a knockoff like 2x

- Bob

Mike,

Are they using the tablet PC in the exact same way they would use a regular workstation? That is, are they running BG-Base (presumably) on this tablet for day to day purposes or are they simply using it as a data collector out in the field? If the latter, you might also consider storing a local copy of BG-Base on the tablet and use a fairly lightweight method for data transfer (like OpenEngine-to-OpenEngine calls) to "synch" the changes back to the main system.

The synch operation can occur wirelessly or after hooking the table back up to a docking station of some kind. We demoed an application that uses this design in New Orleans.

[email protected]

SRP Computer Solutions, Inc.

Hi Don - They are using it basically as a field collector. We are hoping to get around the batch/synching processes by giving them live, direct access to the server.

Mike

I'd suspect it would. Run a packet analyser on your desktop, run OI for a bit, then filter the traffic from your IP to the server IP to elimate the chaff. There's a lot of transfer back and forth, and that's going across the wireless. There's not much you can do besides caching things locally. You can try having some files on the tablet, and some going across the wire, but the end result is, anything that's not cached must be transferred.

By using careful caching and targeting file locations, our wireless apps in the field are about as fast as those on a network.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

Thanks Sprezz -

We can put a copy of our entire app on the tablet, then… modify the .dbt to look at only the data files on the server? The server has a UD, how would the 'local' REVPARAM be configured at that point?

Bob,

This is a good place to mention some things we have found out lately. First, the product XPUnlimited (from the eponymous website) allows a single XP workstation to host multiple remote access sessions, eliminating the need for a Terminal Services server. Second, the Hamachi VPN allows secure cross-subnet application access and printing. Putting these together might allow the home office to host a data collection application anywhere in the field.

Gerald

Thanks Gerald. Those products have a lot of potential.

I like the load balancing features of XPUnlimited.

Hamachi looks very interesting too. I see it is by LogmeIn, a major competitor to WebEx and GoToMeeting, so should be reliable.

It looks like you can make instant private networks across the web.

Thinking out loud …

A product (and price-point) like Hamachi opens the door for subscription based software or distributed databases.

For instance,

With the UD3 and a VPN, each distributed client could have a local subdirectory with a revparam that points to the central server.

for instance if you Installed a full OI on each client, then had a subdirectory on the local machine named "CentralData", with a revparam like

ServerOnly=1

ServerName=CentralServer

ShareName=ReplicatedData

TcpIpPort=23456

NamedPipeName=None

The local client can call ATTACH_TABLE("CENTRALDATA", , )

An mfs and a polling loop could replicate via the central data directory.

A similar technique would let distributed clients pull upgrades from a central location.

This could make it easy keep distributed clients synchronized.

Clients who fail to pay maintenance drop off the VPN, their app works but upgrades stop.

Or

As Don Bakke has suggested, use remote engines to implement a publish and subscribe replication model. Start an engineserver on the client, run an engineserver on the host, use an MFS to trigger 'changed events' on your tables, have the events fire off to the central server which broadcasts out to clients.

The SRP demonstration in Seattle was spectacular. Among many other things they showed the power of their remote engine techniques. Add a web-based VPN such as Hamachi, 3G phone service and a Tablet PC and you can write some really interesting applications.

Sprezz mentioned that careful caching is important too.

I have a sample "READO_MFS" that buffers records in memory on the local workstation. This helps with reporting and popup speed, but selects still happen on the client, so the WAN is still a bottleneck.

I want to write "REMOTE_BFS", so that selects occur on a remote engine, only results cross the wire. Of course, if you use U2 as the back end, you can have that today.

Lots of opportunity, lots of Rev Community people making important contributions. Thanks to all.

Bob

Bob,

Glad you like the product suggestions. This is what you get when you hire a Mac/Linux head who is off at college learning about all the hot, current technology.

We are using paired Linux file/data servers and XPUnlimited machines to provide offices with central systems serving distributed locations. Apparently the Consultants setting up the systems are as excited as I am with the results. We have step-by-step setup instructions on the web, if there is any interest.

Gerald

Bob,

I have read your posting another four times, so I have the following comments. For our systems, the only thing installed on the remote client is the Hamachi VPN and a Program Start File to connect to the XPUnlimited host using RDP. The only thing on the XPUnlimited host is start files, one for each client, to run the AREV or OI applications on the server. Using Gb networking, the Linux server with its SATA drives and UD3 is faster than storing the data on the XPUnlimited host. Since all selects are local, REMOTE_MFS would be moot.

When running AREV, XPUnlimited with Hamachi provides an enormous benefit: the client's printers can be mapped to the XPUnlimited host sessions using "net use" commands because the client and the host share the same virtual subnet.

Regarding subscription software, this becomes really easy to manage. No software other than Hamachi is installed remotely. We use a login nag screen when the subscription is about to expire. Once the subscription does expire, the nag screen changes to an expiration notice. The client can still login, view their data, and enter new records. However, all posting occurs through POST_MFS, which ceases to work once the software subscription expires.

This software arrangement can be setup from a web page, providing a very automated ASP system. Now if I can figure out how to receive payments….

Gerald

You might want to configure it using elements from this knowledge base document on hiding How to Hide Data Files Using Revelation Software's Universal Driver.

[email protected]

The Sprezzatura Group Web Site

World Leaders in all things RevSoft

View this thread on the Works forum...