User`s guide

DAK

KwikNet Overview

1.10 KwikNet TCP/IP Sample Program - A Tutorial

A TCP/IP Sample Program is provided with KwikNet to illustrate the use of the TCP/IP

stack within an application. The sample program is ready for use with the AMX Real-

Time Multitasking Kernel. The sample program has also been tested with each of the

four porting examples provided with the KwikNet Porting Kit.

The sample configuration supports a single network interface. The network uses the

KwikNet Ethernet Network Driver. Because the sample must operate on all supported

target processors without any specific Ethernet device dependence, KwikNet's Ethernet

Loopback Driver is used. Use of this driver provides two benefits: the illustration of a

very simple device driver and an example of its use for testing purposes when network

hardware is not available.

The

KwikNet TCP/IP Stack requires a clock for proper network timing. The examples

provided with the

KwikNet Porting Kit all illustrate the clock interface. However, the

sample program provided for use with AMX has been enhanced to eliminate any

dependence on specific target hardware. This sample program includes a very low

priority task which can detect if you have added a real AMX clock driver to the sample

configuration. If a real hardware clock is not available, this task simulates clock

interrupts, thereby providing AMX ticks which meet KwikNet's needs.

The sample includes two tasks, one acting as a server and the other as a client. In a

multitasking system, these tasks are real tasks managed by the RTOS. In a single

threaded system, the server is attached to the KwikNet Task's server queue and operates in

the KwikNet domain. The client is simply the App-Task executing in the user domain.

The client and server use the KwikNet sockets application programming interface (API) to

communicate. Two scenarios are followed, one after the other.

In the first scenario, the server creates a streaming socket, listens to the socket for a

connection request, accepts a message from the client and generates the correct response.

The client creates a streaming socket, establishes a connection with the server, sends its

request and verifies the proper response.

In the second scenario, the server creates a UDP (connectionless) socket and listens for

incoming requests. The server then uses the socket select feature to wait for the

availability of a message from the client. The server reads the message, identifies the

message source (client) and sends the correct response back to that client. The client

creates a UDP socket, sends its request to the server, waits for the availability of a

message from the server and verifies the proper response.

Once the final scenario has completed, the client calls

KwikNet to log a summary of the

network statistics accumulated during the session.

The sample uses the

KwikNet message recording service (see Chapter 1.7) to record

messages generated by the server, the client and KwikNet. Messages are stored as an array

of strings in memory but can be easily echoed to a console terminal (see Chapter 1.8).