AGW API Delphi VCL and ActiveX Control
Version 0.1 (Alpha)
A Delphi VCL and ActiveX
control to support the AGW Packet Engine API
by Ing. Pedro E. Colla
(LU7DID)
Adrogue – Buenos Aires - Argentina
Table of Contents
What is this ActiveX control for?
Audience.
Disclaimer and License Statement
AGWAPI is suite to implement under Windows 95/98/NT
programming tools that enables the usage ofr the AGW Packet Engineâ.
from any programming environment that supports the technology, primarily C++,
Visual Basic and Delphi 5.
This is performed thru two very closely related
components:
·
AGWAPI
which is a Delphi 5 VCL that implements the class TAGWAPI.
·
AGWAPIX
which is an ActiveX control that implements the class AGWAPIX.
Actually, the ActiveX component is directly derived
from the VCL component thru the usage of the Inprise’s Delphi 5 ActiveX control
wizard.
This control encapsulates the functionality to
access the AGW Packet Engine using either a high and lower level approach.
The application programmer could choose to which
level he wants to interact with the AGW Packet Engine.
The control allows to:
Both the VCL component and the ActiveX control are intended for both the beginner and the seasoned programmer that is willing to develop software for the AGW Packet Engine with a minimum of effort and focusing on the functionality he or she wants to implement rather than the details on how to implement it.
It provides a one-step, drag & drop, facility to plug-in into new or existing programs developed with any major language for the Windows environment, that includes Delphi 5 (either the VCL or the ActiveX control), MS Visual C++ (ActiveX) or Visual Basic (ActiveX).
To install the program the following actions has to
be performed:
The
ActiveX control comes on a file named AGWXnn.ZIP (nn=version), also follow the
instructions of your development environment to install and register a new
ActiveX control.
The AGWPE version required is 2000.70 or later, it won’t work with versions prior to that, so if you have a prior version or you are not sure what version you have just play safe and download a fresh version from SV2AGW’s Home Page
The program itself could run on either Windows 95, Windows 98, Windows NT, Windows 2000 and (probably) on Windows ME, still, the main requisite is to have AGWPE up and running on the target platform you’re planning to use.
The
object architecture is as follows:
MS C++ MS VB Delphi 5 ….. Delphi 5 IDE
The components relies on four low level objects whose details are keep private from the programmer that interacts to implement the different functions required to use the AGW Packet Engine at various levels of functionality.
Those four components are:
All
objects are “wrapped” into a VCL component that manages the export of the
published methods, properties and events in a consistent and uniform way; this
wrapper is also responsible to interact with the Delphi 5 IDE when the VCL is
used and take care of VCL registration issues.
Using
the Inprise’s ActiveX technology the VCL is seamlessy (plus or less)
transformed into an ActiveX control.
The
conversion wizard basically achieves this “magic” thru the following actions
(which is good to understand in order to understand some of the subtle
differences between both components).
The ActiveX Control AGWAPIX is a wrapper of several
objects which presents a consistent interface to the programmer.
All internal objects had been developed using Inprise’s
Delphi 5 VCLs, but that should be transparent to the final programmer; as such
the ActiveX control should be able to be accessed from any major Windows
programming 32 bits environment such as C++, Visual Basic or, of course, Delphi
5.
The different functions of the ActiveX control are
segregated as:
·
Properties.
·
Methods.
·
Events.
Thru the selective definition and filling of them
the programmer could access to different parts of the control functionality.
For a detailed documentation of all the methods,
properties and events please consult the reference documentation.
Be aware that there is one set of documentation for
both the VCL and ActiveX components.
One of the main problems when developing across different lenguages with cross-language libraries is how to map the data types; obviously, all resources uses data types that could be found on all languages. But the documentation refers mostly to Pascal (Delphi 5) data types.
To
make the translation take into consideration that the both the VCL and ActiveX
components had been developed using just 3 different data types to simplify
this issue:
Few initial topics from the programmer standpoint to be enriched as the components evolve and got actual feedback from programmers.
With the components you could approach the usage of AGW Packet Engine from at least three different perspectives:
The low level approach implies to use the components
for little more than to actually skip the implementation of the TCP/IP socket
and some connection details; you’ll gain little or nothing in terms of
productivity and you have to deal with the complete knowledge of the AGW Packet
Engine API. Basically you’ll use one method (AGWWrite) and one event (OnRead)
with relevant properties. Still you’ll benefit a little from a consolidated API
parser (all frames received by the application are already defragmented and
validated as correct) and some relief on the connection/disconnection cycles of
the API. In general requires a fair to good knowledge of the AGW Packet Engine API.
The mid-level approach requires that you need to know
in general how the AGW Packet Engine interacts with an application but you could
address the interaction from a higher level where many detailed tasks (such as sending
queries and manage the asynchronous answer) are mostly solved. The main drawback
of this approach is that you need to manage the connections by yourself. AGW Packet
Engine carries all the connected information for all the connection held by all
the registered callsigns thru the same channel and it’s on the application to differentiate
the status of each connection.
The high level approach allows you to abstract on the
details of how the AGW Packet Engine works and actually see the connections as little
over an abstract implementation that you open, interact with and close thru handles
(like files).
One particularly powerful feature of the AGW Packet Engine which is captured and supported by the components is the ability to work with raw frames (thru the SendRaw method and OnRaw event); there you could implement almost any application you could conceive using the AX.25 protocol. The price is complexity, when going that way you have to implement the full AX.25 protocol state machine.
The
components provides some aids if you wish to go there anyway which are a value add
against working with the Packet Engine alone (such as the capability to decode raw
frames into fields and service functions).
Almost any major program has to implement some sort of cyclic unconnected information delivery (UNPROTO) or to implement some sort of digipeater; those functions are simple (specially the beacon like unproto sender) but still you have to deal with timers, timeouts and the details of the ports.
The components allows to easily deploy both functionalities
domain and to tailor them to your own needs thru the usage of event handlers in
your own code; from a completely automated beacon where you set initially some properties
and everything else is taken care to a complex unproto information delivery service.
Be aware that there are differences on the way the information is processed with low level functions (AGWWrite/OnRead) and the rest regarding the port numbering scheme.
For
some reason George choose to use two different numbering conventions for the ports;
one used by the AGW Packet Engine GUI (1..N) and another for the API (0..N-1).
The
components uses the GUI convention (1..N).
It’s a fair statement to say that the components, albeit several “wrapper” layers are added” do really add too little in terms of footprint and overhead as opposed to develop the things by yourself straight. The ActiveX control is a little bulkier than the VCL component just because of the nature of ActiveX controls.
The key for performance is still to assign the events
and activate the functions that you’re going ot use; there is no point to activate
AGW Packet Engine to send all raw frames and then not implement the event handler
because you don’t use them, the same with monitoring information. Both components
allows a fair degree of control over which information is requested to the AGW Packet
Engine and which not.
Keep your feets dry at all times, you could handle Terabytes
of information by femptosecond on the memory of your machine, but all data eventually
has to be received or sent thru radio ports that had limited bandwidth (and usually
VERY limited bandwidth).
Programmers should support programmers, beside some documentation that I had put together I plan to support the usage of the components mostly thru the Web and E-Mail resources.
Please
refer to
http://www.qsl.net/lu7did/default.htm
For
updates and documentation.
·
Initial
implementation, the underlying objects are well tested and prooven by the usage
but the wrappers are brand new, don’t’ rule out bugs by the truckload; actual
usage would tell. Feedback is important.
·
Documentation
incomplete best that can do at this point.
·
The
Rx/Tx counters on the AX.25 Link Manager has not been implemented yet.
·
Neither
the VCL nor the ActiveX components bring an Icon on the desktop IDE when
dragged and dropped; the VCL component shows an empty square and the ActiveX
component a 0 X 0 icon (that could be enlarged for better view J).
A word about IP Addresses
If your machine is not connected to a LAN and have assigned a
permanent address it is likely that even if your TCP/IP stack is configured you
don’t have a concrete IP ADDRESS to set this program. In that case you should
use what is known as the “loopback” IP Address, which is a
special IP Address that the TCP/IP stack in your machine uses to communicate
with itself. This loopback IP ADDRESS is usually either 127.0.0.1
or 128.0.0.1 and you should not need to configure anything to use
it, it is just there already defined for you. Be aware that if you configure
the loopback IP address all the programs must run on the same
machine, you can not go distributed (aka split the programs in several
machines) without properly configure them as a LAN each one with their own
addressable IP number.
You could tell if your TCP/IP stack knows about the loopback
address by doing on a MS-DOS session the following command
PING 127.0.0.1
If you get an answer such as:
Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Reply from 127.0.0.1: bytes=32 time<10ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4,
Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms,
Maximum = 0ms, Average = 0ms
Your setup will probably work without problems, beware if you
get an answer like the
following:
Pinging 127.0.0.0 with 32 bytes of data:
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Ping statistics for 127.0.0.0:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in
milli-seconds:
Minimum = 0ms, Maximum = 0ms,
Average = 0ms
In the unlikely
event that you try to run this program on an environment that allocates
dynamically the IP Addresses (i.e. using BOOTP or DHCP)
be aware that your IP Address might change over time and you should reflect that
on the configuration if trying to use the programs distributed on several
machines, however, even on such scenario using the loopback IP Address and
everything on the same machine should not create any problem. If you are not
working as a part of a big LAN, say a business environment, you should not be
worried about this scenario.
Please refer to the
documentation of your operating system on how to properly configure the TCP/IP
stack on your machine for further information.
Many people contributed with this program on its
different development stages, I could not account for all of those that thru
conversations (real, air or E-Mail) contributed to create in my mind the
original idea.
The development itself wouldn’t be possible at all without
George Rossopoulos (SV2AGW) providing the AGW Packet Engine (AGWPE)
in the first place, extending the capability to interact with it thru TCP/IP as
opposed to the somewhat arcane DDEML original interface the program had and
lately reacting very promptly to make modifications and enhancements to AGWPE
during the development and test stages.
I look forward for other people to actually use the
program and provide positive or critic feedback of it just drop me a note with
any special requirement or problem you might have.
Initial release. Basic
functionality. Distributed for initial evaluation.
AGWAPI and AGWAPIx are free radioamateur and
experimental uses, commercial use requires written permission from the author.
The author bears no liability for damages related to the usage of this program
nor guarantees the proper functional behaviour. I could certainly be more
sophisticated in legal terms, but in a nutshell use it at your own risk.
Be aware that this is an alpha release more for
evaluation and improvement than actual deployment.
Publicly available information has been used to
understand the requirements, specially the AGWPE TCPIP Interface (AGWSockInterface.DOC
by G.Rossopoulos SV2AGW) and the “AX.25 Amateur Packet Radio Link Layer
Protocol” (AX25.DOC), all code used to implement this program comes from my own
development.
The copyright of what you develop using the control
belongs to the author, still no commercial distribution could be done of it
without my written permission.
If you need support, have suggestions, encountered
some bug or just are willing to provide feedback drop me a note at:
AX.25: LU7DID@LU7DID.#ADR.BA.ARG.SOAM
Inet: [email protected]