Clarion IP Driver

Soft Velocity have released version 2.0 of the popular IP Driver for Clarion - below is an overview of IP Driver 2.0, written by Soft Velocity President and CEO Robert Zaunere.

"The IP Driver and Server (IPD) ver 2.0 is now available. We are pretty happy with the new functionality and features in this release. I thought I'd share with you the ideas behind the new features.

When we reviewed how the IPD v1 was being used we observed a few common themes of usage.

Many developers told us that their primary use of IPD is to provide data access over internal LANs, and WANs used to link multiple offices or sites to the common data files. The inherent reliability of delivery of the TCP layer has proven to deliver both better performance, and much more robust, and reliable data access in WAN settings.

Other developers are using IPD within their LAN to avoid opportunistic locking (oplocks) problems and the related performance hits. Improperly configured Windows networks can lead to data corruption in any file system database. Both opportunistic locking on Windows servers, and read caching on workstations contribute to the potential corruption.

While the oplocks issues can mostly be avoided with some registry changes, in many environments these changes aren't practical or even possible to consistently deploy across the company, especially in larger enterprise deployments. The problem is that you have to manage not just the existing machines, but also the introduction of all new workstations because they won't have the revised registry settings. So managing oplocks
via the registry turns into an ongoing problem that developers want to avoid.

The architecture of the IP Driver/Server is such that all data access is done using TCP/IP to send Clarion I/O commands to the server where they are executed, Oplocks immediately becomes a non-issue because all I/O is done on the "server".

A third common use for the IP driver that is not too surprising is data access over the internet. Some developers use the IPD to provide the opportunity for remote or mobile clients to run their mission-critical applications and access common data over the Internet.

And what we've been told about internet access is that it may mean access over a broadband connection (DSL or Cable), but frequently we've heard that developers require dial-up users to be able to run their applications and connect to the "home office".

With those facts in mind we set about architecting version 2, and here is what we came up with.

Server side VIEWs
We have implemented Server side VIEWs. This means that when the client app opens the VIEW structure as defined in the application, the structure is sent to the server where it is dynamically reconstructed.Server side VIEWs are a great advance over version 1.x because it makes two things true:

1) all filtering is now done on the server
2) only the fields from the VIEW are sent back to the client.

We found a way to do this that allows all code to run "as is", even code that uses filters based on client-side variables!

Multiple Request Packets (MRP)
We have implemented a new technique we have named Multiple Request Packets (MRP), and it is currently supported for ADD, APPEND, NEXT and PREVIOUS statements. We may add other statements later. Its probably easiest to explain MRPs with some example code.

An example of use in code looks like this:

!entity is either a VIEW or a FILE.

entity{PROP:IPRequestCount} = 20 ! client creates a packet with 20 requests
LOOP
   NEXT(entity)                                    ! send packet to server with 20 NEXTs
   ! fill queue/listbox code
END

When the first NEXT is executed in the client app, the request is transmitted to the server, and on the server 20 NEXTs are executed. When the server completes the request one packet is delivered back to the client with the 20 records. On the client side the record
buffer is filled just as if only one NEXT was issued, but the next 19 NEXTs return records from the local packet the client already received. Using PREVIOUS( ) works exactly the same way.

Using ADD/APPEND the code looks like this:

entity{PROP:IPRequestCount} = 10   ! prepare packet with 10 requests
LOOP 10 TIMES
! code to fill the record
   ADD(entity)                                       ! cache request in IP Driver, and
                                                              ! send packet to server on 10th request
END

IF ERRORCODE() ! get number of requests actually executed on the server
nSentRequests = entity{PROP:IPRequestCount}
! code to handle error
END

As you probably noticed any errorcode set on the server become part of the packet. For instance with NEXT, if you tried to read 20 records but on the 15th NEXT you hit EOF, then when the client app tries to read that 15th record in the packet he gets the errorcode 33 that occurred on the server.

We have also chosen certain common file statements and properties, and then optimized the IP driver code so that they work on the client data structure and don't require a trip back to the server.

And we have plans for a Phase 2 implementation for packet compression of the MRPs to reduce network traffic even further, and make the driver even better suited for ADSL solutions. Phase 3 goals are to implement further optimizations for code that can execute client side instead of being sent to the server.

But for the moment what we have completed in version 2.0 it looks to have doubled performance over v1 and made IPD apps usable even over a dialup connection. When we implement phase 2 it will be another big jump in performance for low bandwidth connections.

By the way, you don't have to code anything to make use of Server side VIEWs and MRPs. The VIEW support is automatic, and the templates that ship with 9048 have been changed to make use of MRPs. The impact of both of these new features is much faster Browses, Reports and Processes.

And there is a little bit more, we also added support into the IPD template for the Memory driver. So using MRPs a user can cache data into the memory table and then still use all the regular Browse and related extensions.

Overall we are all very happy with what we accomplished in this release.

We are also discussing plans (speculative) to port the IP driver to .Net compact framework version so that with the Clarion.Net compact version RTL, Clarion programs will be able to talk wirelessly to any backend from any Windows CE enabled device."

Visit SoftVelocity's website.

If you require further information, please call us free on 0800 652 4050

CLARION SERVICES

Clarion IP Driver

Soft Velocity have released version 2.0 of the popular IP Driver for Clarion - below is an overview of IP Driver 2.0, written by Soft Velocity President and CEO Robert Zaunere.

Download Centre:

Newsletter Subscription